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Foreword 


(This Foreword is not a part of the American National Standard Code for Information Interchange, X3 4- 
1977). 


This American National Standard presents the standard coded character set to be used for in- 
formation interchange among information processing systems, communications systems, and 
associated equipment. 

Other standards prescribe the means of implementing this standard in media, such as perforated 
tape, punched cards, magnetic tape, magnetic tape cassettes and cartridges, and optical char- 
acter recognition. Further standards deal with error control, data communication formats, key- 
boards, graphic representation of control characters, code extension techniques, and media 
labels and file structures. 

The 7-bit coded character set was developed from a careful review of past work in the field and 
after a comprehensive program of original research and code design was completed. Careful 
consideration has been given to the several conflicting code set requirements, and their resolu- 
tion is reflected in the standard code. 

This standard is a revision of X3.4-1968, which was developed in parallel with its international 
counterpart, ISO 646-1973. This current revision retains the same technical relationship to ISO 
646-1973 as the earlier edition. However, some definitions have been changed to adopt more 
customary U.S. terminology and to reduce ambiguity. Several previously permitted dualities 
for specific graphics have been eliminated, based on evolving practice in the United States. The 
relationship with the American National Standard Code Extension Techniques for Use with the 
'-Bit Coded Character Set of American National Standard Code for Information Interchange, 
ANSI X3. 41-1974, has also been included. 

Suggestions for improvement of this standard will be welcome. They should be sent to the 
American National Standards Institute, 1430 Broadway, New York, N.Y. 10018. 

This standard was processed and approved for submittal to ANSI by American National Stan- 
dards Committee on Computers and Information Processing, X3. Committee approval of the 
standard does not necessarily mean that all committee members voted for its approval. At the 
time it approved this standard, the X3 Committee had the following members: 


J. F. Auwaerter, Chairman 
R. M. Brown, Vice-Chairman 
W. F. Hanrahan, Secretary 


Organization R epresented Name of Representative 

Addressograph Multigraph Corporation A. C. Brown 

D. D. Anderson (Alt) 

.Air T ransport Association F. C. White 

C. Hart (Alt) 

American Bankers Association M. E. McMahon 

A. Miller (Alt) 

American Library Association J. R. Rizzolo 

J. C. Kountz (Alt) 

M. S. Malinconico (Alt) 

American Nuclear Society D. R. Vondy 

M. K. Butler (Alt) 

American Society for Information Science M. C. Kepplinger 

Association for Computing Machinery P. Skelly 

J. A. N. Lee (Alt) 

H. E.'Thiess (Alt) 

Association for Educational Data Systems A. K. Swanson 

Association of American Railroads R. A. Petrash 

Association of Computer Programmers and Analysts L. A. Ruh 

M. A. Morris, Jr (Alt) 

Association of Data Processing Service Organizations J. B. Christiansen 

Burroughs Corporation E. Lohse 

J. S. Foley (Alt) 

J. F. Kalbach (Alt) 
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Organization Represented 

Computer Industry Association 

Control Data Corporation 

Data Processing Management Association 

Datapoint Corporation 

Digital Equipment Corporation 

Edison Electric Institute 

General Services Administration 

GUIDE International 

Honeywell Information Systems, Inc 

Institute of Electrical and Electronics Engineers, Communications Society 
Institute of Electrical and Electronics Engineers, Computer Society .... 

International Business Machines Corporation 

Joint Users Group 

Life Office Management Association 

Litton Industries 

National Association of State Information Systems 

National Bureau of Standards 

National Communications System 

National Machine Tool Builders’ Association 

NCR Corporation 

Olivetti Corporation of America 

Pitney Bowes, Inc 

Printing Industries of America 

Recognition Equipment, Inc 

Sanders Associates, Inc 

Scientific Apparatus Makers Association 

SHARE Inc 

Society of Certified Data Processors 

Telephone Group 

3M Company 

UNIVAC, Division of Sperry Rand Corporation 

U.S. Department of Defense 

U.S. Department of Health, Education and Welfare 

VIM (CDC 6000 Users Group) 

Xerox Corporation 


Name of Representative 

N. J. Ream 

A. G. W. Biddle (Alt) 

C. E. Cooper 

G. I. Williams (Alt) 

A. E. Dubnow 

D. W. Sanford (Alt) 

V. D. Poor 

H. W. Swanson (Alt) 

P. W. White 

A. R. Kent (Alt) 

S. P. Shrivastava 
J. L. Weiser (Alt) 

D. L. Shoemaker 
M. L. Burris (Alt) 

T. E. Wiese 

B. R. Nelson (Alt) 

D. Stanford (Alt) 

T. J. McNamara 

E. H. Clamons (Alt) 
.(Representation Vacant) 
R. L. Curtis 

T. Feng (Alt) 

.L. Robinson 

W. F. McClelland (Alt) 

T. E. Wiese 

L. Rodgers (Alt) 

R. E. Ricketts 

J. F. Foley (Alt) 

E. J. Jowdy (Alt) 

I. Danowitz 
G. H. Roehm 

J. L. Lewis (Alt) 

G. I. Theis (Alt) 

H. S. White, Jr 

R. E. Rountree (Alt) 

M. L. Cain 

G. W. White (Alt) 

O. A. Rodriques 
R. J. Mindlin 

A. R. Daniels (Alt) 

T. W. Kern (Alt) 

E. J. Almquist 

R. H. Fenn 

E. T. Warzecha (Alt) 

N. Scharpf 

E. Masten (Alt) 

H. F. Schantz 

W. E. Viering (Alt) 

A. L. Goldstein 
T. H. Buchert (Alt) 

A. Savitsky 
J. E. French (Alt) 

T. B. Steel, Jr 
E. Brubaker (Alt) 

T. M. Kurihara 
A. E. Dubnow (Alt) 

V. N. Vaughan, Jr 
J. C. Nelson (Alt) 

P. G. Wray (Alt) 

R. C. Smith 
M. W. Bass 

C. D. Card (Alt) 

W. L. McGreer 

W. B. Rinehuls (Alt) 

W. B. Robertson (Alt) 

W. R. McPherson, Jr 
M. A. Evans (Alt) 

S. W. White 

M. R. Speers (Alt) 

J. L. Wheeler 
A. R. Machell (Alt) 




Subcommittee X3L2 on Character Sets and Codes, which developed this standard, had the fol- 
lowing members: 


C. D. Card, Chairman 


}. B. Booth 
H. Bullard 
C. C. Chandler* 
B. C. Duncan 
T. F. Fitzsimons 

S. M. Garland 
W. L. Hafner 

T. N. Hastings 


M. F. Hill 
T. O. Holtey 
W. F. Huf 
H. F. Ickes 
W. F. Keenan 
T. W. Kern 
J. L. Little 
R. D. Prigge 


Deceased. 


916 


Contents SECTI0N PAGE 

1. Scope 8 

2. Standard Code 8 

3. Character Representation and Code Identification 9 

4. Legend 9 

4.1 Control Characters 9 

4.2 Graphic Characters 9 

5. Definitions 10 

5.1 General 10 

5.2 Control Characters 10 

5.3 Graphic Characters 11 

6. General Considerations 11 

7. Related Standards 12 

7.1 American National Standards 12 

7.2 International Standards 12 

Appendixes 

Appendix A Design Considerations for the Coded Character Set 13 

Al. Introduction 13 

A2. Considerations Affecting the Code 13 

A3. Set Size 13 

A4. Set Structure 13 

.45. Choice of Graphics 13 

A6. Graphic Subset Structure 14 

AT. Control Subset Content and Structure 15 

A8. Collating Sequence 15 

Table Al Punctuation and Diacritical Marks 14 

Appendix B Notes on Application 16 

Bl. Introduction 16 

B2. Character Substitutions 16 

B3. Interoperation of“LF” and“NL” ASCII Equipment 17 

B4. Related Larger and Smaller Sets 17 

B5. International Considerations 17 

B6. Communication Considerations 1° 

Appendix C Original Criteria. 18 

Cl. Introduction 18 

C2. Criteria 18 

Appendix D Revision Criteria and Guidelines 19 

DI. Introduction 19 

D2. The 1977 Revision 20 

D3. Succeeding Revisions 20 

Appendix E Terminology 20 


American National Standard 
Code for Information Interchange 


1. Scope 

This coded character set is to be used for the general interchange of information among information process- 
ing systems, communications systems, and associated equipment. 


2. Standard Code 
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3. Character Representation and Code Identification 

The standard 7-bit character representation, with b 7 the high-order bit and b t the low-order bit, is shown 
below: 

Example: The bit representation for the character “K,” positioned in column 4, row 1 1, is 

b 7 b 6 b s b4 b3 b 2 b t 

10 0 10 11 

The code table for the character “K” may also be represented by the notation “column 4, row 1 1” or 
alternatively as “4/1 1.” The decimal equivalent of the binary number formed by bits b 7 , b 6 , and 
b 5 , collectively, forms the column number, and the decimal equivalent of the binary number 
formed by bits b 4 , b 3 , b 2l and bj, collectively, forms the row number. 

The standard code may be identified by the use of of the notation ASCII. 

The notation ASCII (pronounced 'as-|key) should ordinarily be taken to mean the code prescribed by 
the latest edition of this standard. To explicitly designate a particular (perhaps prior) edition, the last two 
digits of the year of issue may be appended, as, “ASCII 68” or “ASCII 77.” 

4. Legend 

4.1 Control Characters 


CoU 

Row 

Mnemonic and 

Meaning 1 

Col/ 

Row 


Mnemonic and 

Meaning 1 

0/0 

NUL Null 

1/0 

DLE 

Data Link Escape (CC) 

0/1 

SOH Start of Heading (CC) 

1/1 

DC1 

Device Control 1 

0/2 

STX Start of Text (CC) 

1/2 

DC2 

Device Control 2 

0/3 

ETX End of Text (CC) 

1/3 

DC3 

Device Control 3 

0/4 

EOT End of Transmission (CC) 

1/4 

DC4 

Device Control 4 

0/5 

ENQ Enquiry (CC) 

1/5 

NAK 

Negative Acknowledge (CC) 

0/6 

ACK Acknowledge (CC) 

1/6 

SYN 

Synchronous Idle (CC) 

0/7 

BEL Bell 

1/7 

ETB 

End of Transmission Block (CC) 

0/8 

BS Backspace (FE) 

1/8 

CAN 

Cancel 

0/9 

HT Horizontal Tabulation (FE) 

1/9 

EM 

End of Medium 

0/10 

LF Line Feed (FE) 

1/10 

SUB 

Substitute 

0/11 

VT Vertical Tabulation (FE) 

1/11 

ESC 

Escape 

0/12 

FF Form Feed (FE) 

1/12 

FS 

File Separator (IS) 

0/13 

CR Carriage Return (FE) 

1/13 

GS 

Group Separator (IS) 

0/14 

SO Shift Out 

1/14 

RS 

Record Separator (IS) 

0/15 

SI Shift In 

1/15 

US 

Unit Separator (IS) 



7/15 

DEL 

Delete 


1 (CC) Communication Control; (FE) Format Effector; (IS) Information Separator. 
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4.2 Graphic Characters 


Column/Row 

2/0 

2/1 

2/2 

2/3 

2/4 

2/5 

2/6 

2/7 

2/8 

2/9 

2/10 

2/11 

2/12 

2/13 

2/14 

2/15 

3/0 to 3/9 
3/10 
3/11 
3/12 
3/13 
3/14 
3/15 
4/0 

4/1 to 5/10 
5/11 
5/12 
5/13 
5/14 
5/15 
6/0 

6/1 to 7/10 
7/11 
7/12 
7/13 
7/14 


Symbol 

SP 

| 

II 

# 

$ 

% 

& 


+ 


/ 

0 . . . 9 


< 

> 

? 

@ 

A...Z 

[ 

\ 



Name 

Space (Normally Nonprinting) 

Exclamation Point 

Quotation Marks (Diaeresis) 2 

Number Sign 3 

Dollar Sign 

Percent Sign 

Ampersand 

Apostrophe (Closing Single Quotation Mark; Acute Accent) 2 

Opening Parenthesis 

Closing Parenthesis 

Asterisk 

Plus 

Comma (Cedilla) 2 
* Hyphen (Minus) 

Period (Decimal Point) 

Slant 

Digits 0 through 9 
Colon 
Semicolon 
Less Than 
Equals 

Greater Than 
Question Mark 
Commercial At 3 

Uppercase Latin Letters A through Z 

Opening Bracket 3 

Reverse Slant 3 

Closing Bracket 3 

Circumflex 3 

Underline 

Opening Single Quotation Mark (Grave Accent) 2 ’ 3 

Lowercase Latin letters a through z 

Opening Brace 3 

Vertical Line 3 

Closing Brace 3 

Tilde 2 ’ 3 






’The use of the symbols in 2/2, 2/7, 2/12, 5/14, 6/0, and 7/14 as diacritical marks is described in A5.2 of Appendix A. 

’These characters should not be used in international interchange without determining that there is agreement between 
sender and recipient (See Appendix B5.) 
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5. Definitions 
5.1 General 

Control Character. A character whose occurrence in a 
particular context initiates, modifies, or stops an ac- 
tion that affects the recording, processing, transmis- 
sion, or interpretation of data. 

Graphic Character. A character, other than a control 
character, that has a visual representation normally 
handwritten, printed, or displayed. 

(CC) Communication Control. A control character 
intended to control or facilitate transmission of in- 
formation over communication networks. 

(FE) Format Effector. A control character that con- 
trols the layout or positioning of information in print- 
ing or display devices. 

(IS) Information Separator. A control character that is -> 
used to separate and qualify information in a logical 
sense. There is a group of four such characters, which 
are to be used in a hierarchical order. 

5.2 Control Characters 

0/0 NUL (Null). A control character used to accom- 
plish media fill or time fill. Null characters may be in- 
serted into or removed from a stream of data without af- 
fecting the information content of that stream. However, 
the addition or removal of these characters may affect 
the information layout or the control of equipment. 

0/1 SOH (Start of Heading). A communication control 
character used as the first character of a heading of an 
information message. 

0/2 STX (Start of Text). A communication control 
character that precedes a text and is used to terminate 
a heading. 

0/3 EXT (End of Text). A communication control 
character that terminates a text. 

0/4 EOT (End of Transmission). A communication 
control character used to indicate the conclusion of 
a transmission, which may have contained one or 
more texts and any associated headings. 

0/5 ENQ (Enquiry). A communication control char- 
acter used in data communication systems as a re- 
quest for a reponse from a remote station. It may be 
used as a “Who Are You” (WRU) to obtain identifica- 
tion, or may be used to obtain station status, or both. 

0/6 ACK (Acknowledge). A communication control 
character transmitted by a receiver as an affirmative 
reponse to a sender. 


0/7 BEL (Bell). A control character for use when there 
is a need to call for attention. It may control alarm or 
attention devices. 

0/8 BS (Backspace). A one-active-position format ef- 
fector that moves the position backward on the same 
line. 

0/9 HT (Horizontal Tabulation). A format effector 
that advances the active position to the next predeter- 
mined character position on the same line. 

0/10 LF (Line Feed). A format effector that advances 
the active position to the same character position on 
the next line. Where appropriate, this character may 
have the meaning “New Line” (NL), a format effector 
that advances the active position to the first character 
position on the next line. Use of the NL convention 
requires agreement between sender and recipient of 
data. 

0/1 1 VT (Vertical Tabulation). A format effector that 
advances the active position to the same character posi- 
tion on the next predetermined line. When agreed upon 
between the interchange parties, VT may advance the 
active position to the first character position on the 
next predetermined line. 

0/12 FF (Form Feed). A format effector that advances 
the active position to the same character position on a 
predetermined line of the next form or page. When 
agreed upon between the interchange parties, FF may 
advance the active position to the first character posi- 
tion on a predetermined line of the next form or page. 

0/13 CR (Carriage Return (Return)). A format effector 
that moves the active position to the first character posi- 
tion on the same line. 

0/14 SO (Shift Out). A control character that is used in 
conjunction with Shift In to extend the graphic char- 
acter set. It may alter the meaning of the bit combina- 
tions of columns 2 to 7 that follow it until a Shift In 
character is reached. However, the characters Space 
(2/0) and Delete (7/15) are unaffected. The effect of 
this character is described in American National Stan- 
dard Code Extension Techniques for Use with the 7- 
Bit Coded Character Set of American National Stan- 
dard Code for Information Interchange, ANSI X3.41- 
1974. 

0/15 SI (Shift In). A control character that is used in 
conjunction with Shift Out to extend the graphic set. 

It may reinstate the standard meanings of the bit 
combinations which follow it. The effect of this char- 
acter is described in American National Standard 
X3.41-1974. 
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1/0 DLE (Data Link Escape). A communication con-‘ 
trol character that will change the meaning of a limited 
number of contiguously following characters. It is used 
exclusively to provide supplementary data transmission 
control functions. Appropriate sequences are defined 
in American National Standard Procedures for the Use 
of the Communication Control Characters of American 
National Standard Code for Information Interchange in 
Specified Data Communication Links, ANSI X3 28- 
1976. 

1/1-1/4 DC1, DC2, DC3, DC4 (Device Controls). 
Control characters for the control of ancillary devices 
associated with data processing or telecommunication 
systems, more especially switching devices “on” or 
off. (If a single “stop” control is required to inter- 
rupt or turn off ancillary devices, DC4 is the preferred 
assignment.) 

1/5 NAK (Negative Acknowledge). A communication 
control character transmitted by a receiver as a nega- 
tive response to the sender. 

1/6 SYN (Synchronous Idle). A communication con- 
trol character used by a synchronous transmission sys- 
tem in the absence of any other character to provide 
a signal from which synchronism may be achieved or 
retained. 

1/7 ETB (End of Transmission Block). A communica- 
tion control character used to indicate the end of a 
block of data for communication purposes. ETB is 
used for blocking data where the block structure is not 
necessarily related to the processing format 

1/8 CAN (Cancel). A control character used to indi- 
cate that the data with which it is sent are in error or 
are to be disregarded. The specific meaning of this 
character must be defined for each application. 

1/9 EM (End of Medium). A control character that 
may be used to identify the physical end of a medium, 
the end of the used portion of a medium, or the end 
of the wanted portion of data recorded on a medium. 
The position of this character does not necessarily 
correspond to the physical end of the medium. 

1/10 SUB (Substitute). A control character that may 
be substituted for a character that is determined to be 
invalid or in error. 

1/11 ESC (Escape). A control character intended to 
provide supplementary characters (code extension). 

The Escape character itself is a prefix affecting the 
interpretation of a limited number of contiguous bit 
patterns. The effect of this character is described in 
American National Standard X3.41-1974. 
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1/12-1/15 FS (File Separator), GS (Group Separa- 
tor), RS (Record Separator), and US (Unit Separator). 
These information separators may be used with data 
in optional fashion, except that their hierarchical rela- 
tionship shall be: FS as the most inclusive, then GS, 
then RS, and US as least inclusive. (The content and 
length of a file, group, record; or unit are not speci- 
fied.) 

7/15 DEL (Delete). A character used primarily to erase 
or obliterate an erroneous or unwanted character in 
punched tape. DEL characters may also serve to ac- 
complish media fill or time fill. They may be inserted 
into or removed from a stream of data without affect- 
ing the information content of that stream. However, 
the addition or removal of these characters may affect 
the information layout or the control of equipment, 
or both. 

5.3 Graphic Characters 

NOTE: No specific meaning is prescribed for any of the 
graphics in the code table except that which is understood by 
the users. Furthermore, this standard does not specify a type 
style for the printing or display of the various graphic char- 
acters. In specific applications it may be desirable to employ 
distinctive styling of individual graphics to facilitate their use 
for specific purposes. 

2/10 SP (Space). A graphic character that is usually 
represented by a blank site in a series of graphics. The 
space character, though not a control character, has a 
function equivalent to that of a format effector that 
causes the active position to move one position for- 
ward without producing the printing or display of any 
graphic. Similarly, the space character may have a func- 
tion equivalent to that of an information separator. 


6. General Considerations 

6.1 This standard does not define the means by which 
the coded set is to be recorded in any physical 
medium, nor does it include any redundancy or define 
techniques for error controL Further, this standard 
does not define data communication character struc- 
ture, data communication formats, code extension 
techniques, or graphic representation of control char- 
acters. 

6.2 Deviations from the standard may create serious 
difficulties in information interchange and should be 
used only with full cognizance of the parties involved. 

6.3 The relative sequence of any two characters, when 
used as a basis for collation, is defined by their binary 
values. The Null character (position 0/0) will be ranked 
low and the Delete character (position 7/15) will be 
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ranked high. Other collating sequences may be used by 
prior agreement between interchanging parties. 

6.4 The representation of this 7-bit code in an 8-bit 
environment is specified in American National Stan- 
dard X3.41-1974. 

6.5 The Appendixes to this standard contain addi- 
tional information on the design and use of this code. 

7. Related Standards 

7.1 American National Standards 

Perforated Tape Code for Informal. on Interchange, 
ANSI X3. 6-1965 (R1973) 

Recorded Magnetic Tape for Information Interchange 
(200 CPI, NRZI), ANSI X3. 14-1973 

Bit Sequencing of the American National Standard 
Code for Information Interchange in Serial-by-Bit Data 
Transmission, ANSI X3. 15-1976 

Character Structure and Character Parity Sense for 
Serial-by-Bit Data Communication in the American 
National Standard Code for Information Interchange, 
ANSI X3. 16-1976 

Character Set and Print Quality for Optical Character 
Recognition (OCR-A), ANSI X3. 17-1977 

Recorded Magnetic Tape for Information Interchange 
(800 CPI, NRZI), ANSI 3.22-1973 

Character Structure and Character Parity Sense for 
Parallel-by-Bit Communication in the American Na- 
tional Standard Code for Information Interchange, 
ANSI X3. 25-1976 

Hollerith Punched Card Code, ANSI X3.26-1970 

Magnetic Tape Labels and File Structure for Informa- 
tion Interchange, ANSI X3.27-1977 

Procedures for the Use of the Communication Control 
Characters of American National Standard Code for 
Information Interchange in Specified Data Communi- 
cation Links, ANSI X3. 28-1976 

Graphic Representation of the Control Characters of 
American National Standard Code for Information 
Interchange, ANSI X3.32-1973 


Recorded Magnetic Tape for Information Interchange 
(1600 CPI, PE), ANSI X3. 39- 1973 

Code Extension Techniques for Use with the 7-Bit 
Coded Character Set of American National Standard 
Code for Information Interchange, ANSI X3.41- 

1974 

Specifications for Character Set for Handprinting, 
ANSI X3.45-1974 

Magnetic Tape Cassettes for Information Interchange 
(3.810-mm [0.015-in] Tape at 32 bpmm [800 bpi] , 
PE), ANSI X3 .48- 1977 

Character Set for Optical Character Recognition (OCR- 
B), ANSI X3 .49- 1975 

Recorded Magnetic Tape for Information Interchange 
(6250 CPI, Group-Coded Recording), ANSI X3.54- 
1976 

Recorded Magnetic Tape Cartridge for Information 
Interchange (4 Track, 0.250 in [6.30 mm] , 1600 bpi 
[63 bpmm] , PE), ANSI X3.56-1977 

Structure for Formulating Message Headings for In- 
formation Interchange Using the American National 
Standard Code for Information Interchange for Data 
Communication System Control, ANSI X3. 57-1977 

Alphanumeric Keyboard Arrangements Accommodat- 
ing the Character Sets of American National Standard 
Code for Information Interchange and American Na- 
tional Standard Character Set for Optical Character 
Recognition, ANSI X4. 14- 1971 

7.2 International Standards 4 

7- Bit Coded Character Set for Information Processing 
Interchange, ISO 646-1973 

Information Processing — Basic Mode Control Pro- 
cedures for Data Communication Systems, ISO 1745- 

1975 

Code Extension Techniques for Use with the ISO 7-Bit 
Coded Character Set, ISO 2022-1973 


"Publications of the International Organization for Standard- 
ization are available from the American National Standards In- 
stitute, 1430 Broadway, New York, N.Y. 10018. 
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Appendix A 

Design Considerations for the Coded Character Set 

Al. Introduction 

The standard coded character set is intended for the 
interchange of information among information pro- 
cessing systems, communication systems, and associ- 
ated equipment. 

A2. Considerations Affecting the Code 

There were many considerations that determined the 
set size, set structure, character selection, and character 
placement of the code. Among these were (not listed in 
order of priority): 

(1) Need for adequate number of graphic symbols 

(2) Need for adequate number of device controls, 
format effectors, communication controls, and in- 
formation separators 

(3) Desire for a nonambiguous code, that is, one in 
which every code combination has a unique interpreta- 
tion 

(4) Physical requirements of media and facilities 

(5) Error control considerations 

(6) Special interpretation of the all- zeros and all- 
ones characters 

(7) Ease in the identification of classes of char- 
acters 

(8) Data manipulation requirements 

(9) Collating conventions 

(a) Logical 

(b) Historical 

(10) Keyboard conventions 

(a) Logical 

(b) Historical 

(11) Other set sizes 

(12) International considerations 

(13) Programming Languages 

(14) Existing coded character sets 

A3. Set Size 

A 7-bit set is the minimum size that will meet the re- 


quirements for graphics and controls in applications 
involving general information interchange. 

A4. Set Structure 

A4.1 In discussing the set structure it is convenient to 
divide the set into eight columns and sixteen rows as 
indicated in this standard. 

A4.2 It was considered essential to have a dense subset 
that contained only graphics. For ease of identification 
this graphic subset was placed in six contiguous columns. 

A4.3 The first two columns were chosen for the con- 
trols for the following reasons: 

(1) The character NUL by its definition has the 
location 0/0 in the code table. NUL is broadly con- 
sidered a control character. 

(2) The representations in column 7 were felt to be 
most susceptible to simulation by a particular class of 
transmission error — one that occurs during an idle 
condition on asynchronous systems. 

(3) To permit the considerations of graphic subset 
structure described in Section A6 to be satisfied, the 
two columns of controls had to be adjacent. 

A4.4 The character set was structured to enable the 
easy identification of classes of graphics and controls. 

A5. Choice of Graphics 

AS.l Included in the set are the digits 0 through 9, 
uppercase and lowercase Latin letters A through Z, and 
those punctuation, mathematical, and business symbols 
considered most useful. The set includes a number of 
characters commonly encountered in programming lan- 
guages. In particular, all the COBOL and FORTRAN 
graphics are included. 

AS.2 In order to permit the representation of lan- 
guages other than English, two diacritical (or accent) 
marks have been included, and provision has been 
made for the use of four punctuation symbols altema- 
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Table A1 

Punctuation and Diacritical Marks 


Col / 
Row 

Code Table 
Symbol 

Use 

Puncutation 

Diacritical 

2/2 

II 

Quotation marks 

Diaeresis 

2/7 

' 

Apostrophe 

Acute accent 

2/12 

. 

Comma 

Cedilla 

5/14 


(None) 

Circumflex 

6/0 

' 

Opening single 

Grave accent 



quotation mark 


7/14 


(None) 

Tilde 


tively as diacritical marks in conjunction with back- 
space. The pairing of these punctuation symbols with 
their corresponding diacritical marks was done to facili- 
tate the design of a typeface that would be acceptable 
for both uses. ■> 

These arrangements are given in Table Al. 


A6. Graphic Subset Structure 

A6.1 The basic structure of the dense graphic subset 
was influenced by logical collating considerations, the 
requirements of simply related 6-bit sets, and the needs 
of typewriter-like devices. For information processing 
it is desirable that the characters be arranged in such a 
way as to minimize both the operating time and the 
hardware components required for ordering and 
sequencing operations. This requires that the relative 
order of characters, within classes, be such that a 
simple comparison of the binary codes will result in 
information being ordered in a desired sequence. 

A6.2 Conventional usage requires that SP (Space) 
be ahead of any other symbol in a collatable set. This 
permits a name such as “JOHNS” to collate ahead of 
a name such as “JOHNSON.” The requirement that 
punctuation symbols such as comma also collate ahead 
of the alphabet (“JOHNS, A” should also collate be-' 
fore “JOHNSON”) establishes the special symbol loca- 
tions, including SP, in the first column of the graphic 
subset. 

A6.3 To simplify the design of typewriter-like devices, 
it is desirable there be only a common 1-bit difference 
between characters to be paired on keytops. This, to- 
gether with the requirements for a contiguous alpha- 
bet and the collating requirements outlined above, re- 
sulted in the placement of the alphabet in the last four 
columns of the graphic subset and the placement of the 
digits in the second column of the graphic subset. 


A6.4 It is expected that devices having the capability 
of printing only 64 graphic symbols will continue to be 
important. It may be desirable to arrange these devices 
to print one symbol for the bit pattern of both upper- 
case and lowercase of a given alphabetic letter. To 
facilitate this, there should be a single-bit difference 
between the uppercase and lowercase representations 
of any given letter. Combined with the requirement 
that a given case of the alphabet be contiguous, this 
dictated the assignment of the alphabet, as shown in 
columns 4 through 7. 

A6.5 To minimize ambiguity caused by the use of a 
64-graphic device as described above, it is desirable, to 
the degree possible, that each character in column 6 or 
7 differ little in significance from the corresponding 
character in column 4 or 5. In certain cases this was 
not possible. 

A6.6 The assignment of reverse slant and vertical line, 
the brackets and braces, and the circumflex and tilde 
were made with a view to the considerations of A6.5. 

A6.7 The resultant structure of “specials” (S), “digits” 
(D), and “alphabetics” (A) does not conform to the 
most prevalent collating convention (S-A-D) because of 
other code requirements. 

A6.8 The need for a simple transformation from the 
set sequence to the prevalent collating convention was 
recognized, and it dictated the placement of some of 
the “specials” within the set. Specifically, those special 
symbols, namely, ampersand (&), asterisk (*), comma 
(,), hyphen (-), period (.), and slant {[), that are most 
often used as identifiers for ordering information and 
normally collate ahead of both the alphabet and the 
digits were not placed in the column containing the 
digits. Thus the entire numeric column could be ro- 
tated via a relatively simple transformation to a posi- 
tion higher than the alphabet. The sequence of the 
aforementioned “specials” were also established to the 
extent practical to conform to the prevalent collating 
convention. 

A6.9 The need for a useful 4-bit numeric subset also 
played a role in the placement of characters. Such a 4- 
bit subset, including the digits and the symbols asterisk, 
plus (+), comma, hyphen, period, and slant, can easily 
be derived from the code. 

A6.10 Considerations of other domestic code sets, 
including the Department of Defense former standard 
8-bit data transmission code (“Fieldata”-1961), as well 
as international requirements, played an important role 
in deliberations that resulted in the code. The selection 
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and grouping of the symbols dollar sign ($), percent 
sign (%), ampersand (&), apostrophe ('), Less than 
(<), equals (=), and greater than (>) facilitate contrac- 
tion to either a business or scientific 6-bit subset. The 
position of these symbols, and of the symbols comma, 
hyphen, period, and slant, facilitates achievement of 
commonly accepted pairing on a keyboard. The his- 
toric pairing of question mark and slant is preserved 
and the less than and greater than symbols, which have 
comparatively low usage, are paired with period and 
comma, so that in dual-case keyboard devices where it 
is desired to have period and comma in both cases, the 
less than and greater than symbols are the ones dis- 
placed. Provision was made for the accommodation of 
alphabets containing more than 26 letters and for 6-bit 
contraction by the location of low-usage characters in 
the area following the alphabet. 

A 7 . Control Subset Content and Structure 

A 7.1 The control characters included in the set are 
those required for the control of terminal devices, 
input and output devices, format, or communication 
transmission and switching, and are general enough to 
justify inclusion in a standard set. 

A7.2 Many control characters may be considered to 
fall into the following categories: 

(1) Communication Controls 

(2) Format Effectors 

(3) Device Controls 

(4) Information Separators 

To the extent that was practical, controls of each cate- 
gory were grouped in the code table. 

A7.3 The information separators (FS, GS, RS, US) 
identify boundaries of various elements of informa- 
tion, but differ from punctuation in that they are 
primarily intended to be machine sensible. They were 
arranged in accordance with an expected hierarchical 
use, and the lower end of the hierarchy is contiguous 
in binary order with SP (Space), which is sometimes 
used as a machine-sensible separator. Subject to this 
hierarchy, the exact nature of their use within data 
is not specified. 

A7.4 The character SYN (Synchronous Idle) was lo- 
cated so that its binary pattern in serial transmission 
was unambiguous as to character framing, and also to 
optimize certain other aspects of its communication 
usage. 

A7.5 ACK (Acknowledge) and NAK (Negative Ac- 
knowledge) were located so as to gain the maximum 


practical protection against mutation of one into the 
other by transmission errors. 

A7.6 The function “New Line” (NL) was associated 
with LF (rather than with CR or with a separate char- 
acter) to provide the most useful combinations of 
functions through the use of only two character posi- 
tions, and to allow the use of a common end of line 
format for printers having separate CR-LF functions 
as well as for printers having a combined (that is, NL) 
function. This sequence would be CR-LF, producing 
the same result on printers of both classes, and would 
be useful during conversion of a system from one 
method of operation to the other. 

A7 .7 This standard is enhanced by the inclusion of the 
option “New Line” which conforms to traditional elec- 
tric typewriter practice. Data processing keyboard im- 
plementors are cautioned of a potential confusion be- 
tween the use of the terms “Return” and “New Line.” 
The large key on the right side of keyboards has often 
been marked Return, although it sometimes accom- 
plishes a “New Line” function, rather than a “Return” 
function (which according to this standard only has a 
horizontal motion). 

A7.8 The function “Vertical Tabulation” (VT) and 
“Form Feed” (FF) are defined to advance the active 
position to the same character position of the sub- 
sequent line similarly to “Line Feed.” By agreement, 
these functions may also return the active position to the 
first character position on the subsequent line. The 
practice of preceding either of these characters with 
“CR” may be useful during conversion, as with “LF.” 


A8. Collating Sequence 

This supplements the consideration of collating se- 
quence in Section A6. 

It is recognized that the collating sequence defined 
in 6.3 of this standard cannot be used in many specific 
applications that define their own sequence. In some 
applications, groups of characters may be assigned ex- 
actly equal collating weight to preserve an initial order- 
ing. In other applications a different sequence may be 
desired to meet the needs of the particular application. 
Nonetheless, it was deemed essential to define a stan- 
dard sequence and standard results for comparisons of 
two items of data, to serve the needs of many applica- 
tions. 

The standard sequence will facilitate, but will not 
provide directly by means of simple sorting, the order- 
ing of items customarily found in (1) algebraically 
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signed data, in which the largest positive value is high 
and the largest negative value is low, and (2) complex 
alphabetic listings, such as those found in telephone 
directories, library catalogs, or dictionaries. However, 


Appendix B 
Notes on Application 


Bl. Introduction 

Bl.l The standard code was developed to provide for 
information interchange among information processing 
systems, communications systems, and associated 
equipment. In a system consisting of equipment with 
several local or native codes, maximum flexibility will 
be achieved if each of the native codes is translated to 
the standard code whenever information interchange 
is desired. 

Bl .2 Within any particular equipment, system, or 
community of activity, it may be necessary to substi- 
tute characters. For example, some systems may re- 
quire special graphic symbols, and some devices may 
require special control codes. (Design efforts on the 
standard code included consideration of these types of 
adaptations.) So-called “secular sets” produced by such 
substitutions, though not conforming to this standard, 
may nonetheless be consonant with it if substitutions 
are made in accordance with the guidelines of Section 
B2. 

B1.3 In recognition of these requirements for control 
and graphic characters, additional national and interna- 
tional standardization efforts beyond those provided in 
this standard are in progress to extend the 7-bit code. 

The techniques for this extension are provided by Inter- 
national Standard ISO 2022-1973, Code Extension Tech- 
niques for Use with the ISO 7-Bit Coded Character Set, 
and by American National Standard X3. 41-1974. Stan- 
dards for additional graphic character sets and for con- 
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general use of these standard collating sequences and 
standard comparison evaluations will facilitate the 
transfer of programs and the general interchange of 
data among various computer systems. 


trol character sets for displays and enhanced printing 
devices are currently under development. 

B2. Character Substitutions 

B2.1 Any character substitution will result in a coded 
character set that does not conform to this standard. 

B2.2 It is recommended that when a character is sub- 
stituted in the code table for a standard character, the 
standard character should not be reassigned elsewhere 
in the table. Such a substitute character, once assigned, 
should not be subsequently reassigned elsewhere. 

B2.3 It is recommended that graphic substitutions be 
made only in the graphic area and control substitutions 
only in the control area. Any substitution involving a 
control should be made only with full cognizance of 
all possible operational effects. 

B2.4 It should be noted that this standard specifies, 
for each position of the code table, the information 
represented by the character and not necessarily the 
precise action taken by the recipient when the char- 
acter is received. In the case of graphics, considerable 
variation in the actual shape printed or displayed may 
be appropriate to different units, systems, or fields of 
application. In the case of controls, the action per- 
formed is dependent upon the use for which the 
particular system is intended, the application to which 
it is being put, and a number of conventions estab- 
lished by the user or designer — some system-wide and 
some unique to a particular unit. 
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B2.5 Typical examples of diversity in execution not 
necessarily contrary to this standard are: 

(1) A number of graphic symbols, other than those 
used in the code table, are used for ampersand in vari- 
ous type styles; still other symbols may be more ap- 
propriate to electronic display devices. The use of such 
alternate symbols does not in itself constitute deviation 
from the standard as long as ampersand is the concept 
associated with the character. Note that this does not 
necessarily restrict the use of such an alternate symbol 
design to mean “and”; in any type style ampersand 
may, of course, be used with arbitrary meaning. 

(2) A card punch in one application may “skip” 
when the character HT (Horizontal Tabulation: used as 
skip) is presented to it; in another application the char- 
acter HT may be recorded in the card without further 
action. 


B3. Interoperation of “LF” and a NL” 

ASCH Equipment 

Several bit pattern sequences in ASCII will cause a de- 
vice receiving these sequences to move its active posi- 
tion to the first (leftmost) column and also move the 
active position down one row. Some of these sequences 
are: 

Using “Line Feed” convention: 

CR LF 
CRCR LF 
CR CR LF DEL 

Using “New Line” option: 

NL 

CR NL 
CR CR NL 
CR CR NL DEL 

where DEL (Delete) is merely a “time waster” to ac- 
commodate mechanical devices. The functions involv- 
ing only horizontal motion are shown preceding those 
involving vertical motion for the reason that mechanical 
devices may require more time to accomplish the hori- 
zontal motion. 

Interoperation of equipment conforming to the 
ASCII control conventions of CR (Carriage Return) 
and LF (Line Feed) with equipment conforming to 
the optional control NL (New Line) in position 0/10 
can be assured if the operational sequences CR NL or 
CR CR NL or CR NL DEL or CR CR NL DEL are al- 
ways used to move the active position to the first posi- 
tion of the next line. The sequence CR NL sent from 
an “option” device will be received by a “conventional” 
device as CR LF, and the reaction will be the desired 


one. Likewise, the sequence CR LF sent from a “con- 
ventional” device will be received as CR NL on an “op- 
tion” device, and reaction will be as desired. 


B4. Related Larger and Smaller Sets 

Consideration has been given to the relationship be- 
tween the standard set and sets of other sizes. A num- 
ber of straightforward logical transformations are pos- 
sible, which result in a variety of sets related to the 
standard. None of the transformed sets is recognized 
by this standard, except through the related standards 
concerning code extension. 


B5. International Considerations 

B5. 1 General. This standard conforms to the recom- 
mendations of the International Organization for Stan- 
dardization (ISO), and the International Telegraph and 
Telephone Consultative Committee (CCITT) 5 for a 7- 
bit code. It includes all the character assignments speci- 
fied by those bodies for international standardization. 
Their recommendations, however, permit national stan- 
dardization by the various countries in seven code table 
positions. Also, the characters in three additional posi- 
tions have been designed as “supplementary” use posi- 
tions, which are replaceable by national characters in 
only those countries having an extraordinary require- 
ment in this regard. 

The ten National Use positions and their assign- 
ments in this standard are as follows: 

Column/Row 

National use: 

4/0 
5/11 
sin 
5/13 
7/11 
7/12 
7/13 

Supplementary national use 
5/14 
6/0 
7/14 


1 An international body that establishes standards and conven- 
tions for international telecommunications, especially where 
the public telegraph and telephone services are governmentally 
owned and operated. Their recommendations are often em- 
bodied in the regulations applying to such services. " 


Character (U.S.) 


@ 

[ 

\ 

] 

{ 

I 

} 
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In international interchange of information these ten 
characters should not be used except where it is deter- 
mined that there is agreement between sender and re- 
cipient. In such an interchange, where accented letters 
are to be formed via combinations of graphics and 
backspace, users are cautioned that other standards 
prescribe the syntax of such constructs rigidly. 

In addition, in other countries, the number sign (#) 
(in position 2/3) may be replaced by “£”, and the 
dollar sign ($) (in position 2/4) may be replaced by the 
currency symbol ( n ). 

B5.2 International Reference Version. The related 
standard, ISO 646-1973, describes an “International 
Reference Version” (IRV). The IRV is the default case 
of ISO 646-1973 in the lack of need of a defined na- 
tional version. The CCITT permits international inter- 
change using the IRV. 

The graphic characters of this standard (ASCII) are 
consistent with the IRV with the exception of the * 
following two positions: 

Column/Row Character fU.SJ Character (IRV) 

-/4 5 (currency sign) 

7/14 ‘ (overline) 

B5.3 International Terminology Differences. Where 
practical, this standard has adopted terminology in use 
in the English version of associated international stan- 
dards. Variations from this are due to the demands of 


Appendix C 
Original Criteria 


Cl . Introduction 

Cl .1 This Appendix contains the original criteria upon 
which the design of the code was based. Not all criteria 
have been entirely satisfied. Some are conflicting, and 
the characteristics of the set represent accepted com- 
promises of these divergent criteria. 

Cl. 2 The criteria were drawn from communication, 
processing, and media recording aspects of informa- 
tion interchange. 


common American usage and the desire for consistency 
with prior versions of this standard. 


B6. Communication Considerations 

Certain control characters are designated as “Com- 
munication Controls.” They are: 

SOH (Start of Heading) 

STX (Start of Text) 

ETX (End of Text) 

EOT (End of Transmission) 

ENQ (Enquiry) 

ACK (Acknowledge) 

DLE (Data Link Escape) 

NAK (Negative Acknowledge) 

SYN (Synchronous Idle) 

ETB (End of Transmission Block) 

These may be used by communication systems for 
their internal signaling or for the exchange of informa- 
tion relating to the control of the communication sys- 
tem between that system and its end terminals. Some 
such systems may impose restrictions on the use of 
these communication control characters by the end 
terminals. For example, the use of some of them may 
be completely prohibited; others may be restricted to 
use in conformity with the formats and procedures re- 
quired by the communication system for its operation. 


C2. Criteria 

C2.1 Every character of the code set shall be repre- 
sented by the same number of bits. 

C2.2 The standard set shall be so structured as to 
facilitate derivation of logically related larger or smaller 
sets. 

C2.3 In a code of n bits, all possible 2" patterns of 
ones and zeros will be permitted and considered valid. ' 
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C2.4 The number of bits, n , shall be sufficient to 
provide for the alphabetic and numeric characters, 
commonly used punctuation marks, and other special 
symbols, along with those control characters required 
for interchange of information. 

C2.5 The digits 0 through 9 shall be included with- 
in a 4-bit subset. 

C2.6 The digits 0 through 9 shall be so represented 
that the four low-order bits shall be the binary-coded- 
decimal form of the particular digit that the code 
represents. 

C2.7 The interspersion of control characters among 
the graphic characters shall be avoided. The characters 
devoted to controls shall be easily separable from those 
devoted to graphics. 

C2.8 Within the standard set, each character shall 
stand by itself and not depend on surrounding char- 
acters for interpretation. 4 

C2.9 An entire case of the Latin alphabet (A through 
Z) shall be included within a 5-bit subset. Considera- 
tion shall be given to the need for more than 26 char- 
acters in some alphabets. 

C2.10 The letters of each case of the alphabet shall 
be assigned, in conventional order (A through Z), to 
successive, increasing binary representations. 

C2.1 1 Suitable control characters required for com- 
munication and information processing shall be in- 
cluded. 

C2.12 Escape functions that provide for departures 
from the standard set shall be incorporated. 


Appendix D 

Revision Criteria and Guidelines 

Dl. Introduction 

Dl.l This Appendix has been added to assist users of 
the standard. The criteria used in coming to a given re- 


C2.13 A simple binary comparison shall be suffi- 
cient to determine the order within each class of 
characters. (In this regard, the special graphics, the 
digits, and the alphabet are each defined as distinct 
classes.) Simple binary rules do not necessarily apply 
between classes when ordering information. 

C2.14 Space must collate ahead of all other graphics. 

C2.1 5 Special symbols used in the ordering of in- 
formation must collate ahead of both the alphabet 
and the digits. 

C2.16 Insofar as possible, the special symbols shall 
be grouped according to their functions; for example, 
punctuation and mathematical symbols. Further, the 
set shall be so organized that the simplest possible 
test shall be adequate to distinguish and identify the 
basic alphabetic, numeric, and special symbol subsets. 

C217 Special symbols shall be placed in the set so 
as to simplify their generation by typewriters and 
similar keyboard devices. This criterion means, in ef- 
fect, that the codes for pairs of characters that nor- 
mally appear on the same keytops on a typewriter 
shall differ only in a common single-bit position. 

C2.18 The set shall contain the graphic characters 
of the principal programming languages. 

C2.19 The codes for all control characters shall con- 
tain a common, easily recognizable bit pattern. 

C2.20 The Null (0000000) and Delete (1111111) 
characters shall be provided. 


vision are briefly stated in this Appendix. Also in- 
cluded are guidelines now in use as well as recom- 
mended guidelines for successive revisions (at the 
mandatory 5-year intervals). 
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D1.2 The criteria listed here have been adopted from 
many sources. Primarily they have come from users 
of the 1968 edition of this standard or from sugges- 
tions by others involved in international standards. 


D2. The 1977 Revision 

D2.1 General. The 1968 edition was reviewed and re- 
vised to bring terminology into more consistent U.S. 
practice. 

D2.2 Graphics. The primary considerations in revision 
of the graphics area of the standard were: 

(1) Elimination of formerly recognized dualities 
(positions 2/1,5/14). These allowed stylization of 
these characters to reflect their possible usage as logical 
OR and NOT, respectively. Evolving practice has shown 
these to be unnecessary. 

(2) Elimination of a formerly recognized duality 
(position 2/3), which allowed substitution of the 
“Pound Sterling” symbol. Evolving practice has shown 
this to be unnecessary. 

(3) Clarification of conflict between graphic shape 
and description (position 7/12). 

D2.3 Controls. The primary considerations in revision 
of the controls area of the standard were: 

(1) To adopt definitions consistent with associ- 
ated standards (positions 0/14, 0/15, and 1/11). 

(2) To make no change of substance to the com- 
munications controls without the explicit request of 
the group responsible for data communication pro- 
cedures. 

(3) To accommodate the definitions of the con- 


Appendix E 
Terminology 

This Appendix is intended to clarify the sense in which 
certain terms are used. 

Active Position. That character position in which the 
character about to be processed would appear. The ac- 
tive position normally advances one character position 
at a time. 

Bit. Contraction of “binary digit.” 


trols of ISO 646-1973 wherever domestic conflicts did 
not exist. 

(4) To clarify definitions where use application 
had given indications of need for clarification. 

(5) To recognize evolving practice aimed at pro- 
viding an “optional implicit CR” function with all 
three vertical movement Format Effectors (positions 
0 / 10 , 0 / 11 , 0 / 12 ). 

D3. Succeeding Revisions 

D3.1 General. A review will be made for domestic and 
international consistency of use. 

D3.2 Controls. A study will be made in the following 
areas: 

(1) Communications Controls 

(2) Information Separators 

(3) Format Effectors 

(4) Device Controls 

Each group will be evaluated from the viewpoint of 
current usage, suitability of the definitions, possible 
improvement of definitions, potential replacement by 
more desirable functions, or any combinations thereof. 

D3.3 Graphics. A study will be made concerning the 
following positions: 

(1) 5/12 

(2) 5/14 

(3) 6/0 

(4) 7/14 

If characters of more frequent usage emerge in U.S. 
practice, these positions will be evaluated for potential 
replacement. This is entirely consistent with the cau- 
tions described in Appendix B, wherein the national 
use considerations were introduced. 


Bit Pattern. The binary representation of a character. 

Character. A member of a coded character set; the 
binary representation of such a member and its graphic 
symbol or control function. 

Code. A system of discrete representations of a set of 
symbols and functions. 
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Federal Information 
Processing Standards Publication 1_1 
1980 DECEMBER 24 

ANNOUNCING THE STANDARD FOR 

CODE FOR INFORMATION INTERCHANGE 


FIPS PUB 1-1 


" e 0 



Federal Information Processing Standards Publications are issued by the 
National Bureau of Standards pursuant to section 111(f)(2) of the Federal 
Property and Administrative Services Act of 1949, as amended, Public Law 89- 
306 (79 Stat. 1127), Executive Order 11717 (38 FR 12315, dated May 11, 1973) 
and Part 6 of Title 15 Code of Federal Regulations (CFR). 

1. Name of Standard. Code for Information Interchange (also commonly known 
as, "Ask-Ee"), ASCII (FIPS 1-1). 

2. Category of Standard. Hardware and Software Standard, Interchange 
Codes, Media, and Data Files. 

3. Explanation. This standard specifies a code and character set for use 
in Federal information processing systems, communications systems, and 
associated equipment. FIPS PUB 1 (1968) excluded the "New Line" (NL) 
option contained in the definition of "Line Feed" (LF) of American National 
Standard X3 . 4-1968. The revised ASCII standard, X3 . 4-1977, makes only minor 
revisions to X3. 4-1968. All of X3. 4-1977 is adopted as FIPS 1-1, including 
the "New Line" option. 

4. Approving Authority. Secretary of Commerce. 

5. Maintenance Authority. U.S. Department of Commerce, National Bureau of 
Standards (Institute for Computer Sciences and Technology). 

6. Cross Index. American National Standard X3. 4-1977, Standard Code for 
Information Interchange (ASCII). 

7. Related Documents. 

a. ISO Standard 646-1973, 7-Bit Coded Character Set for Information 
Processing Interchange. 

b. CCITT Recommendation V3 , 1972, International Alphabet No. 5. 

c. American National Standard X3. 41-1974, Code Extension Techniques for 
Use with the 7-Bit Coded Character Set of American National Standard Code 
for Information Interchange (FIPS PUB 35). 

d. ISO Standard 2022-1973, Code Extension Techniques for Use with the 
ISO 7-Bit Coded Character Set. 

e. American National Standard X3. 64-1979, Additional Controls for Use 
with the American National Standard Code for Information Interchange, FTPS 86. 

f. ISO Standard 6429, Additional Controls for Character Imaging 
Devices . 

g. ISO Standard 1745-1975, Information Processing — Basic Mode Control 
Procedures for Data Communication Systems. 

h. American National Standard X3. 57-1977, Structure for Formulating 
Message Headings for Information Interchange Using ASCII for Data 
Communication System Control . 

i. American National Standard X4. 14-1971, Alphanumeric Keyboard 
Arrangements Accommodating the Character Sets of ASCII and American National 
Standard Character Set for Optical Character Recognition. 

j. FIPS PUB 2, Perforated Tape Code for Information Interchange (X3.6- 
1965). 

k. FIPS PUB 3-1. Recorded Magnetic Tape for Information Interchange 
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FIPS PUB 1-1 

(800 CPI, NRZI) (X3. 22-1973) . 

l. FIPS PUB 14-1, Hollerith Punched Card Code (X3 . 26- 1980 ) . 

m. FIPS PUB 15, Subsets of the Standard Code for Information ; ■ 

Interchange. „ , . T - . . • -'v 

n. FIPS PUB 16-1, Bit Sequencing of the Code for Information ' t* 

Interchange in Serial— by— Bit Data Transmission ( X3 . 15— 1976) • 

o. FIPS PUB 17 — 1, Character Structure and Character Parity Sense for ,*r» 

Serial-by-Bit Data Communication in the Code for Information Interchange ■ . 

/ xb 10 — 1^76) inH 

p . fxPS PUB 18-1, Character Structure and Character Parity Sense for 
Parallel-by-Bit Data Communication in the Code for Information Interchange 

q. FIPS PUB 25, Recorded Magnetic Tape for Information Interchange 

(1600 CPI, Phase Encoded) ( X3 . 39-1973) . 

r. FIPS PUB 32, Optical Character Recognition Character Sets (X3.17— 

1977) and ( X3 . 49-1975) . . 

s. FIPS PUB 33, Character Set for Handprinting (X3 .45-1974) . ^ 

t. FIPS PUB 35, Code Extension Techniques in 7 or 8 Bits ( X3 . 41-1974) . 

u. FIPS PUB 36, Graphic Representation of the Control Characters of 

ASCII ( X3 . 32-1973) . ■■’-irflB 

v. FIPS PUB 50, Recorded Magnetic Tape for Information Interchange, 

6250 cpi (246 cpmm) , Group Coded Recording (X3 .54-1976) . ..*5 

w. FIPS PUB 51, Magnetic Tape Cassettes for Information Interchange 
(3.810 mm [0.150 inch] Tape at 32 bpmm [800 bpi ] , Phase Encoded) (X3.48- 
1977 } 

x. FIPS PUB 52, Recorded Magnetic Tape Cartridge for Information 

Interchange, 4-Track, 6.30 mm (1/4 inch), 63 bpmm (1600 bpi), Phase Encoded 

1977^ 1 

y. FIPS PUB 86, Additional Controls for Use with ASCII (X3 .64-1979) . 

z! ISO Standard 4873-1979, 8-Bit Coded Character Set for Information | 
Interchange . 

8. Applicability. Generally applicable to the representation of character 

coded information in information interchange and files used in data 

processing, communications, and related equipment, as detailed in I 

7, Implementation of the Code for Information Interchange and Related Media 
Standards. Information concerning the use of this standard "-dj 

communications systems that are a part of the National Communications ysem^; 
may be obtained from the Manager, National Communications System, Attention. j| 
NCS-0, Washington, DC 20305. 

9. implementation Schedule. All computers and related equipment 

configurations brought into the Federal Government i"^°^ v ° n ° r ft 
effective date of this FIPS PUB must have the capability to use tnis , 

standard. All applicable equipment ordered aft ®^ ^^pg^gg 3 ^ ® r an* <4 
conformance with this standard, a subset as described by FIPS PUB 15 or an m 
extension as described by FIPS PUB 35, unless a waiver has been obtained in . J 
accordance with FIPS PUB 7 . 

10. Specifications. This standard adopts in whole American National : 

Standard X3. 4-1977, Standard Code for Information Interchange (ASC ). : 

11. Qualifications. None. 

12. Waivers. See FIPS PUB 7. 

13. Where to Obtaih Copies. Copies of this publication are 

CommerceT" Springfield] “£ 2 2 

refer^ to 6 Federal standards Wblle^lj 

J-l (Ss-pSi-l-I). and title. Payment may be made by check, money order ,,sd| 
credit card, or NTIS deposit account. _ • Sf 


U.S. GOVERNMENT PRINTING OFFICE : 1981 0 - 338-444 
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FIPS PUB 7 

(Supplement to FIPS 
PUBS 1, 2 and 3) 



£\ Federal Information 

I* 

Processing Standards Publication 7 
-3 March 7, 1969 

IMPLEMENTATION OF THE CODE FOR 
INFORMATION INTERCHANGE AND RELATED 
MEDIA STANDARDS 


Federal Information Processing Standards Publications are issued by the National Bureau of Standards under 
the direction of the Bureau of the Budget in accordance with the provisions of Public Law 89-306 and Bureau 
of the Budget Circular No. A-86. 
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PURPOSE.— To provide further details concerning the implementation and applicability of the Federal 
Information Processing Standards (FIPS), Code for Information Interchange (FIPS 1), Perforated Tape 
Code for Information Interchange (FIPS 2), and Recorded Magnetic Tape for Information Interchange 
(800 CPI, NRZIXFIPS 3). 

EXPLANATION.— White House memorandum to heads of departments and agencies, dated March 11, 
1968, signed by President Lyndon B. Johnson approved as Federal Standards the United States of 
America Standard Code for Information Interchange and associated standards for recording the code on 
perforated and magnetic tape media. (Copy of this memorandum is attached as app. A.) Also the 
memorandum stated that the Department of Commerce would provide details of these standards and 
their application. 

These standards were announced through the FEDERAL INFORMATION PROCESSING 
STANDARDS REGISTER on November 1, 1968 as FEDERAL INFORMATION PROCESSING STAN- 
DARDS PUBLICATIONS 1, 2 and 3. These FIPS PUBS noted that the Secretary of Com- 
merce by separate letter addressed to the heads of Federal departments and agencies would 
provide details concerning implementation plans and specific areas of application, and when 
released, information concerning this letter would be the subject of a future FIPS PUB. 

The Secretary of Commerce on March 7, 1969, released the implementation letter cited above. 
This letter and accompanying instructions (attached as app. B) supplement the information contained 
in FIPS PUBS 1, 2 and 3. 

Questibns concerning these standards publications or their application as well as comments or 
recommendations for revision should be directed to the National Bureau of Standards, Center for 
Computer Sciences and Technology, Washington, D.C. 20234. 
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appendix a 


THE WHITE HOUSE 

WASHINGTON 


March 11, 1968 


MEMORANDUM FOR THE HEADS OF 

DEPARTMENTS AND AGENCIES 


I have today approved a recommendation by the Secretary of 
Commerce , submitted under provisions of Pub 1 
that the United States of America Standard Code for Infor 
mation Interchange be adopted as a Federal standard. 

In my memorandum to you of June 28, 1966 ' 1 ® tr *Jeat efcom- 
need for achieving, with industry cooperation, greater com 

patibility among computers. The earlier adoption 
Standard Code for Information Interchange as a voluntary 
standard by the United States of America Standards Institute 
reflects a national concern with this need. 

The adoption of this code as a Federal standard is a major 

step toward minimizing costly incom ? atib ^ 1 i ty <; ^°ems OUr 
Federal computer and telecommunications data systems. 

I have also approved recommendations of the Secretary ° f 
Commerce regarding standards for recording 
for Information Interchange on magnetic tapes and paper 
tapes when they are used in computer operations. 

All computers and related equipment julv 9 ^ 

gS.^^tSTSSKiiS^ S/S. and cod^r 

magnetic^ tap^andtpaper these miia are 

used. 

netwIrkfofthfNattinafco^uniLtiSnsiystefwhoSe^rteary 

function is either the transmission of record communica 
or^h^transmission of data related to 

in . Th(a standard will be implemented on a time pnasea 
bSIis St is to be specified in National Communications 
System long-range plans. 







1 


3 





The heads of departments and agencies are authorized to 
waive the use of these standards only under compelling cir- 
cumstances of particular applications. Such waiver is to be 
coordinated with the Department of Commerce (National Bureau 
of Standards) before it is exercised so that the Department 
may effectively accomplish the goals of the Federal computer 
equipment standards program conducted under Public Law 89-306. 

The Department of Commerce will provide you with the details 
of these standards and their application. 
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APPENDIX B 

THE SECRETARY OF COMMERCE 

WASHINGTON, D.C. 20230 

March 7, 1969 


MEMORANDUM FOR THE HEADS OF 

DEPARTMENTS AND AGENCIES 




SUBJECT: Application of Federal ADP Code 

and Media Standards 

By Memorandum addressed to the Heads of 
Deoartments and Agencies on March 11, 19 ° 8 ' F 1 ® 
SXiSS directed that all computers and related 
equipment configurations brought into ' the Federa 
Government inventory on and after ^ly 
must have the capability to use the American 
Standard Code for Information In terchange £A! ) 

and ancillary standards. Th ® These 

providing Federal agencies with derails - - 

standards and their application has been delegate 
to the Department of Commerce. 

The attachment to this memorandum provides 
the details referred to by the President. 
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Maurice H. Stans 


Attachment 







APPLICATION OF FEDERAL ADP CODE AND MEDIA STANDARDS 



1. Introduction 

Public Law 89-306 authorized the Secretary of 
Commerce to make appropriate recommendations 
to the President relating to the establishment 
of uniform Federal automatic data processing 
standards. The President, on March 11, 1968, 
approved as Federal standards the USA Standard 
Code for Information Interchange (ASCII), as 
well as standards implementing the Standard 
Code in perforated tape and magnetic tape media 
(see Attachments 1 and 2). The announcement 
also delegated the responsibility of providing 
details on these standards and their ap- 
plication to the Secretary of Commerce. A 
glossary of the specialized terms employed in 
this paper is included as Attachment 3. 

2. Purpose 

The purpose of this memorandum is to identify 
the objectives of these standards and relate 
the specific standards to these objectives, and 
to provide instructions for application. 

3. Objectives 

The objectives of Public Law 89-306 are to 
provide for the economical and efficient pur- 
chase, lease, maintenance, operation and utili- 
zation of automatic data processing equipment 
by Federal departments and agencies. The 
development, adoption and implementation of 
appropriate information processing systems 
standards will contribute to the objectives of 
P L. 89-306 by providing such benefits as: 

a. Improved cost effectiveness in the pro- 
curement and continued use of information 
processing systems and equipment, includ- 
ing supporting software. 

b. Extension of the economic benefits of data 
processing and computing through increased 
compatibility between and within systems, 
sharing of facilities among users, and 
simplified methods and procedures for the 
use of information processing facilities. 


c. Increased freedom of selection of equip- 
ment which conforms to compatibility stan- 
dards, and hence increased competition 
among suppliers of information processing 
equipment and supporting services. 

d. Greater flexibility in the use of programs 
and data in computers provided by all sup- 
pliers, facilitated by appropriate stan- 
dards for compilers and validation 
techniques. 

One of the vital elements in realizing these 
objectives is the provision of the highest 
practical level of compatibility for the inter- 
change of information in machine-processible 
form within and between information systems, 
including input/output equipment, source data 
automation equipment, other associated equip- 
ment, and communication systems. This includes 
the maximum use of standard programming 
languages and recording techniques so as to 
minimize the need for reprocessing, reordering, 
or converting of information in information 
processing operations. 

A standard coded character set, standards 
which prescribe the method of representing the 
coded character set in media used for input/- 
output purposes, and a standard collating 
sequence, are also basic requirements for com- 
patible interchange of data in automatic data 
processing operations. It is becoming increas- 
ingly difficult to distinguish between data 
which will always remain inside the originating 
installations and that which may now or later 
be needed elsewhere. Moreover, an installation 
under one manager’s control and performing only 
the tasks of a single organizational unit now 
is frequently spread over multiple locations, 
or may have many remote terminals. In such a 
situation the distinction between internal and 
external information flows almost disappears. 

Use of the same character set, code, media and 
collating sequence for installation files 
eliminates the need for such distinctions and 
hence will facilitate interchange. 

It is the intention of the Federal ADP Stan- 
dards program that all installations adopt the ij 
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ASCII code, media and sequence standards and 
that progress be made toward this objective in 
as rapid a manner as is economically and 
technically feasible. 

These Federal ADP standards do not extend to 
the internal structure of the central process- 
ing unit or peripheral devices. In general, 
therefore, computers may operate in any mode 
and use any internal code which the equipment 
manufacturer deems most efficient. 

4. Scope of Application 

The President’s memorandum of March 11, 1968, 
and these instructions, apply to computers and 
related equipment configurations brought into 
the Federal inventory or acquired or leased 
with Federal funds as set forth in Paragraph 3, 
BoB Circular A-54 Revised June 27, 1967. They 
also apply to data systems developed for imple- 
mentation by or for Government agencies, and to 
data developed outside the Federal Government 
at Government expense if such data is to be a 
part of the data base of a Federal agency. 
Related equipment includes all character- 
oriented equipment in which magnetic tape or 
perforated tape is produced for input to a 
computer based data system or received as 
output from a computer based data system. 
These instructions also apply when transmission 
terminal equipment and facilities are procured 
primarily in support of a computer based data 
system. 

The President’s memorandum applies to new or 
used equipment brought into the inventory from 
outside. Complete systems and systems 
components can also be transferred between 
agencies, or between installations within an 
agency. The General Services Administration 
facilitates such transfers by availability no- 
tices. Whenever equipment is available through 
these avenues which conforms to or can be 
adapted to the standards, it will be given 
preference over equipment which does not con- 
form and cannot be adapted. 

Central processor, peripheral or other re- 
lated equipment used substantially full time as 
part of the control element in a larger system, 
where that larger system (weapons control, for 
instance, or a manufacturing process) is not 
itself primarily concerned with information 
activities, is not within the scope of 



application of these Federal standards. How- 
ever, since general purpose equipment used in 
these systems may be used elsewhere at a later 
date, agencies should conform to the ASCII s 
standards wherever possible. 

5. Instructions for Implementing 
the Standards 

Most of the computers and related equipment 
currently in use by the Federal Government are 
of a generation which pre-dated the approved 
Federal ADP standards. In view of the Gov- 
emment’s investment in this equipment, the G, 
transition to these standards will be made on 
an evolutionary basis as equipment is replaced 
or added, computers are reprogrammed and data 
systems are redesigned. It is not the inten- : 
tion at this time to require the immediate con- 
version of existing data systems and equipment 
for the sole purpose of conforming to Federal ’Hg 
ADP standards. Utilization of existing non- 
standard systems and equipments should be |j 
continued as long as economically advantageous. 

On the other hand, when a system con- 
version of any magnitude is planned (new or 
more powerful hardware, machine-independent 
software or, especially, remote-access opera- -|S 
tion), an agency must not only conform to the . 
Presidential order by acquiring the prescribed '€,*?$*• 
hardware or software capability, but must 
include in its plans the actual introduction of r|jj 
ASCn character set, code, media and sequence 'f® 
standards as soon as consideration of economics 
and personnel permit. While techniques for , 
interchange shall be given priority, intro- . 
duction of the standards for character coded 
data and program storage within installations 
and conversion of appropriate existing files'"' j 
shall also proceed as rapidly as possible. GGjja 

Specifically, when interchange and internal ^ 
file techniques are updated from Hollerith, bi- Gj 
nary-coded decimal, pure binary and six-bit-;^ 
oriented codes and media, the ASCII character,. . 
code, media and sequence standards shall 
applied. In no case may a non-standard alter-, j 
native be introduced. 

More efficient utilization of magnetic gtaf 
and other media for interchange and for instal- 
lation files is sometimes realized by the usa 
of non-standard techniques (packed numerics, , 
floating point, pure binary). Where such! 
techniques have already been adopted, local us 
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may be continued until Federal standards 
applicable to these techniques are promulgated. 
To facilitate United States of America 
Standards Institute (USASI) and Federal 
standards development, agencies making heavy 
use of such techniques should advise the 
National Bureau of Standards of the form, 
degree and length of use, application, and 
technical or cost advantages of the representa- 
tions used. If the use of these techniques 
established prior to the issuance of applicable 
Federal standards is to carry past a replace- 
ment or augmentation procurement, the waiver 
procedure (see sec. 9) must be followed. 

The memorandum of March 11 requires that all 
computers and related equipment configurations 
brought into the Federal Government inventory 
on and after July 1, 1969, must have the capa- 
bility to use ASCII and the formats prescribed 
by the magnetic tape and paper tape standards 
when these media are used. The following 
instructions apply: 

a. New Installations. The standard code and 
the magnetic tape and paper tape standards 
shall be implemented in new additions to 
the inventory, and their use must be spe- 
cified in requests for proposals in all 
cases where there are no significant 
existing tape files or program libraries 
which prevent their immediate use. The 
supporting software shall be compatible 
with the character set, code, media and 
collating sequence of the approved Federal 
standards. 

b. Replacement of Computers and Related 
Equipment. Introduction of replacement 
computers often involves reprogramming and 
file conversion. Such reprogramming and 
file conversion may be completed when the 
replacement becomes operational, particu- 
larly if the data system has undergone 
major revision. In this case, the 
standards and supporting software shall be 
fully applied upon conversion. If the 
reprogramming and file conversion is to be 
completed over a prescribed time period, 
the standards shall be phased in as the 
reprogramming and conversion is accom- 
plished. 

Replacement equipment added to the 
inventory which does not require signifi- 


cant reprogramming effort must immediately 
utilize the approved standards wherever 
technically possible and economically 
feasible. 

c. Augmentation of an Existing Computer 
Configuration. It is sometimes necessary 
to augment an existing computer installa- 
tion with additional computer, peripheral 
or related equipment which must make use 
of the same media files as the older 
equipment. In this case, use of the 
standards may have to be deferred until 
segments, subsystems or the entire system 
can be converted to the standards. Added 
equipment should if possible have ASCII 
capability; if not, the waiver procedure 
(see sec. 9) must be invoked. New capa- 
bilities added to an existing installation 
or system, such as remote terminals or a 
source data acquisition subsystem, should 
make use of the approved standards wher- 
ever technically possible and economically 
feasible. If the full character set of 
ASCII cannot be applied, the largest 
possible character subset (see sec. 8) 
should be used, and the ASCII collating 
sequence observed. 

6. Interchange Between Installations 

One of the benefits to be derived from char- 
acter set, code, collating sequence and input/- 
output media standardization is improved 
ability to exchange data between installations 
of computers and related equipment. The full 
benefits of standardization will be realized as 
input/output equipment which uses the standards 
replaces the present inventory. The ASCII 
character set and implementing input/output 
media standards shall be used whenever data is 
interchanged between two installations which 
have equipment conforming to the standard. The 
standards also can be used effectively for 
interchange between installations even though 
some of the installations involved do not yet 
use the standard media within their data 
processing operations. 

Agencies which already receive large quan- 
tities of machine-readable submissions from 
other Government sources or from outside 
organizations are often required, usually em- 
powered, and almost always expected, to specify 
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acceptable media, codes and formats. For this 
reason, and because the Federal ASCII standards 
are in exact accord with the USASI national 
character, code, media and sequence standards, 
such agencies should take the lead in utilizing 
ASCII techniques themselves, and are encouraged 
to require it of their sources at the earliest 
practical date. 

7. ADP — Telecommunications Interface 

ASCII is also a standard for telecom- 
munication networks. Some Federal telecom- 
munications systems operate in ASCII; others 
will when updated in conformance with the plan 
for the National Communications System 
(administered by the Office of Telecommuni- 
cations Management in the Executive Office of 
the President). Therefore, users of all com- 
puter systems and components which will use 
Federal communications sytems for the 
transmission of data shall consult with the' 
Office of Telecommunications Management as to 
interface requirements. 

8. Character Sets 


bols). Still others may require a very much 
larger set (general library applications, 
cartography, typesetting). 

Permitted character sets are as follows: 

a. Basic or standard set. Use of ASCII as 
promulgated and officially maintained by 
USASI, and as registered in the National 
Bureau of Standards FEDERAL INFORMA- 
TION PROCESSING STANDARDS REG- 
ISTER (FIPS Register). This should be 
used wherever the capability exists and 
wherever additional graphic or control 
characters are not absolutely necessary. 

b. Subsets. Use of a smaller number of ASCII 
characters, the individual character code 
assignments remaining unchanged. Examples 
are a 16-character “numeric” subset and 
various high speed printer subsets. Use 
of one or more of these ASCII subsets is a 
powerful tool in bridging the conversion 
gap prior to the procurement or 
utilization of hardware with full ASCII 
capability. 

c. Extended sets. Use of alternate assign- 
ments of the 128 binary patterns. This 



ASCII defines a set of 128 characters com- 
monly used in information processing and 
communications. Ninety-four characters of the 
set are graphic symbols (upper and lower case 
alphabet, decimal digits, punctuation and 
special symbols); thirty-two are used for 
control functions; the remaining two are 
“space” and “delete.” This set of 128 
characters, • when coded in binary format, 
requires a minimum of seven bits for a unique 
representation of each character. Repre- 
sentation of this binary code on standard- 
conforming paper tape is by seven bits. 
Representation on standard-conforming magnetic 
tape is by eight bits. The magnetic tape 
standard specifies that the eighth bit will be 
recorded as “zero.” The recording of “one” in 
the eighth channel will be governed by the 
procedures for expanded sets specified in 
paragraph d. below. Many computing, data 
processing, and communications applications 
require only a limited character set. Other 
applications may require a character set of 
about the ASCII size, but with very different 
graphics (Cyrillic alphabet, mathematical sym- 


may be accomplished by use of the ASCII 
control characters SO (Shift Out), SI 
(Shift In) and ESC (Escape). Such use may 
be planned by agencies having special 
requirements, but must not be finalized 
until approved by NBS and entered in the 
FIPS Register. Once an extended set has 
been identified and approved and entered 
in the FIPS Register it may be used for 
applications and by installations other 
than the original without specific ap- 
proval by NBS. 

d. Expanded sets. Use of the complete 256 
eight-bit character codes made possible by 
the availability of eight information 
channels on standard magnetic tape and 
other media with a capacity for eight data 
bits. The character set of the expanded 
code must include the character set of the 
original code. Use of expanded sets must 
be approved by NBS and entered in the FIPS 
Register as described above for extended 
sets. Once an expanded set has been 
identified and approved and entered in the 
FIPS Register it may be used for 
applications and by installations other 


-iv/AV 

■ #- 


10 



p 


than the original without specific ap- 
proval by NBS. 

The approval and registration of ex- 
tended and expanded sets will prevent un- 
controlled character code assignments from 
leading to incompatibilities like those 
which preceded the adoption of ASCII. The 
register of approved code assignments will 
be of great value in developing future 
national and Federal code standards. 

9. Waivers 

In Section 3, the objectives of the Federal 
ADP standards program are enumerated. Section 
5 provides instructions for furthering these 
objectives through implementation of the ASCII 
standards, and recognizes current situations 
from which evolutionary progress toward the 
objectives will be achieved. If instances 
arise in which an agency cannot comply with the 
provisions of Section 5, the head of the agency 
is authorized to waive application of these 
instructions. Generally, two conditions apply 
in those exceptional cases which would warrant 
waivers: 

a. Significant, continuing cost or efficiency 
disadvantages will be encountered by the 
use of ASCII and, 

b. The interchange of information with other 
systems is minimal and is expected to re- 
main minimal. 

All waivers and the reasons therefore will be 
coordinated with the National Bureau of Stan- 
dards sufficiently in advance of final agency 
authorization that NBS may consider the impact 
of the decision on the Federal standards pro- 



gram, and the significance of the action with 
respect to future national standards partici- 


pation. 

A waiver will not be required for equipment 
delivered before July 1, 1969, nor for equip- 
ment ordered before March 11, 1968 for delivery 
on or after July 1, 1969. Equipment ordered 
after the issuance of the Presidential order 
and before the issuance of this memorandum, for 
delivery on or after July 1, 1969, and not 
conforming to the Federal standards, shall be 
described in memorandum form to the National 
Bureau of Standards within sixty days of j 

issuance of this letter. In exceptional cases, 
such as an important and entirely new 
installation, NBS may request initiation of the 
full waiver procedure by the agency head. 


10. Additional Information 


Questions related to these standards or their 
application as well as comments or recommenda- 
tions for revisions of these standards should 
be directed to the Center for Computer Sciences 
and Technology, National Bureau of Standards, 
Washington, D.C. 20234. 


Attachment 1: 

Approved Federal ADP Standards 
Attachment 2: 

Additional ADP Standards Under Development 

Attachment 3: 

Glossary of Terms 
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Interview 

with 

Bob Berner 
by 

J. A. N. Lee 
February 23, 1982 
Berner Home 

2 Moon Mountain Trail 
Phoenix, A2 85023 

With Annotations by Flo Pessin, 82/11/12. 
[Printed 83/05/26] 


Lee : 


Let me start by asking about your biographical background 
before you started the FOR TRANSIT project. 


L£ : I came to IBM from Lockheed Missiles (I started that 

installation). Then they got an [Univac] 1103, and I had 
been espousing the [IBM] 701 before going there. [Charlie] 
DeCarlo came down and kindly offered to take me to New York 
for an interview, which he did in November of 1955. He took 
me to lunch at Rubens and bought me a couple of whiskey 
sours. On the way home from lunch we saw [T.J.] Watson 
senior toddling (sort of) along the sidewalk, and I said 
between the two things, indications were that I could live 
with IBM. What he wanted me for was to do something about 
the scientific side of the 705. Dr. George Petrie, who was 
managing the 705 there, had been listening to all on the 
commercial side, but he kept stuffing all the letters about 
scientific use in the drawer. Finally people got desperate, 
so Charlie [DeCarlo] asked if I could make some type of a 
processor for the 705 so they could run scientific programs 
on it. 


Lee: IBM in that era (mid 50 's and all through mid 60’ s) still 

had this very distinct dichotomy between the scientific 
machines and the commercial machines. 

Berner : Yes they did, except the customers kept telling them that 

they might possibly do some scientific work. 

Lee: Again, you remember that when George Radin was talking 

about the development of PL/I at the HOPL* he said that even 
in '64 we were still talking about that problem. 


* The History of Programming Languages Conference, held in 
Los Angeles CA in 1978, sponsored by ACM. 
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Berner: Yes, but if you look the early specs on Commercial 

Translator, when it was COMTRAN, you will find that the 
arithmetic statements were virtually FORTRAN. I was trying 
to get them together at that time. That was the whole idea 
with XTRAN. 

Lee : DeCarlo was the one that was involved in '55 and that is 

interesting because DeCarlo came back into the FORTRAN 
picture as John's manager half-way through as well. 

When he picked you up out of Lockheed had you really had any 
experience with languages or translators up to that point? 

Berner : Oh, yes, I had done much of the FLAIR system for the 650, 
which turned out to be quite popular. A lot of people used 
that. And before that, the first thing I ever did was 
Brown's method of game playing for the CPC, and then I did a 
couple of floating point boards for the CPC, one of which was 
with Bob Bosak. In fact, they were quite interesting, 
because we were able to put on four separate program tracks 
and branch, so we had decision making on the CPC. 

Lee : And knowing those boards at that time, they were pretty 

horrendous to do, just to get printing done, let alone 
anything else. 

Berner : And the first time I had any high level contact with IBM 

people was when John McPherson came around one time when I 
was at Lockheed, California, and I was showing a floating 
point, self-checking board on the CPC. He was extremely 
interested, and cancelled his plane reservations and stayed 
over to go through it with me. 

Lee : Now Dave Hemmes was with you at Lockheed as well. What was 

Dave working on? 

Berner : No, Dave wasn't at Lockheed (California), he came from 

Rand Corp. When I went from Lockheed to start the 
installation at Marquardt, among the people I hired there was 
Dave Hemmes. 

Lee : Now, was he also working in Language areas at that time? 

Berner : No, he was running data reduction, CPC stuff, and he just 

naturally fell into it, I guess. Then we went over to 

Lockheed Missiles and started working on the [IBM] 650 
System. 

Lee: So you joined IBM in late '55, and then for some period you 
were working on the 705 scientific side of the business. So 
how did you get over from the 705 scientific to catch on to 
the tail end of John' s FORTRAN and start FOR TRANSIT? 
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Berner: I gave a paper on the design of the PRINT system in 

February (1956), 2 months after I started working there. And 
then we had the thing running in August. Even though it was 
mostly contract labor from CUC and a couple of other people 
outside. I suppose that by this time I had gotten enough of 
John McPherson's confidence that he said "what would you like 
to do for an encore?" I did the PRINT system while sitting 
in the opposite end of this large room where all the FORTRAN 
work was done. A big open room, with just one office 
required for John, and I guess Dave (Dave Sayre, was 
assistant manager by that time) sat there, I don't think I 
had an office. That's when they formalized it and Dave and -I 
reported to John, except John never paid any attention to me. 
This was slightly before we moved to the Langdon Hotel, in 
the 56/57th Street area. 

Lee : McPherson was the one who essentially gave you a blank 

check and said "what are you going to do now?" and for some 
reason you chose to piggyback on FORTRAN. 

Berner : I started to get interested about compatibility between 

machines. First, I wanted to use them because of the 
scientific side of the 705. And I said, I guess to myself, 
if you can do that, you can go between machines. I knew that 
also, because the FLAIR system was later put on a different 
machine, I think it was an 1101 at Convair. So I said there 
has got to be a way of moving this stuff. 

Lee : Now when you had the concept of implementing a FORTRAN on 

the 650 -- 

Berner : I knew I couldn't start from scratch like John did. 

Lee : But also at that point, presumably you didn't have any 

thoughts about the cascading approach or the IT process. 

Berner : Yes, I did! I had met Perlis at a University of Michigan 

session I think it was in '56, (I suppose in one summer 
session, I've got a note from John Carr on that). I knew 
Perlis from Purdue as well, and they had talked about the 
stuff they were doing and then later he went to Carnegie. So 
I knew they had a processor except that the language was 
different, or else it was the superstructure that was 
different. And after 3 years work on FORTRAN, you can't go 
up to McPherson and say "why don't we start the same thing 
for the 705 or the 650?" 

Lee : By that time John had spent 25 man [i] years on producing 

FORTRAN and though the number of 650 's was going to be much. 


[i] Pessin points out that it really should not be expressed 
as man years since Lois Haibt was a member of the team! 
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much larger than the 704' s, the price was going to be 
somewhat lower. So presumably the economic benefit was not 
there, or was it timing which was pushing you? I get the 
impression that you almost wanted to beat John to the punch. 

Berner : Yes!!!! There was always a rivalry, because Buick up at 

Flint and Pontiac used PRINT on the 705; They also used 
FORTRAN. Then they told me that some of these processes that 
they were doing on the 705 were beating the 704. So I just 
said, well wouldn't it be nice if FORTRAN moved over on the 
650. 

Lee : So you put a team together - - 

Berner : I had to go out to Carnegie in Pittsburgh, on 1956 

December 6-8 and get permission first. 

Lee : - - to use IT? Now it was also piggybacked on SOAP? You 

got the idea for FOR TRANSIT, that is cascading from FORTRAN 
to IT to SOAP and eventually through to object code. Who was 
the first person you brought on board? 

Berner : Hemmes, Dave Hemmes. I set him the task of designing the 

system. 

Lee : You used the same language but you had to back off a little 

because the machine was smaller, so there was no language 
design being done. 

Berner : Yes, we were concerned with the construction of the 

compiler . 

Lee : Then Otto Alexander came along? 

Berner : Yes and then Flo [Pessin] and Leroy [May]. 

Lee : In talking to Flo - she said that her job really was [to 

design] the arithmetic analyzer for expressions. 

Berner : That's correct. 

Lee : But what were the others there doing? Do you remember? 

Berner : To tell you the truth I don't! I floated in and out 
because at the same time I was beginning to work on COMTRAN 
-- (set memberships types of operations -- but we had to back 
off on that because we didn't know how to do that in those 
days). I guess really you could say McPherson gave me such a 
free hand and so much encouragement, that I began starting 
off like Norman Lear - who is a "developer" of TV shows - he 
doesn't direct shows, he just gets them going. 
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Lee : Why, for example, couldn't you have grabbed someone from 

the FORTRAN group - or were they all too busy? 

Berner : They were dedicated, they couldn't be moved - that was 

the first example of Conway's Law - the compiler you get, and 
the piece of software produced, will always reflect the 
organization that produced it. 

Lee : Then essentially they were so tied in to their own schedule 

and so tied to the 704 so there was no way they could help? 
Did you get any consulting from them? 

Berner : Very informally. In fact, very little. 

Lee : Were they over-committed? Now John had committed the 704 

[FORTRAN] over and over again. 

Berner : No, we had not told anybody except very informally. As 

far as I recall there was no early IBM announcement of 650 
FOR TRANSIT. 

Lee : In essence then you didn't have that kind of pressure -- 

but you had rivalry pressure. You also fell into the same 
mistake [looking back after 25 years] that John's group had 
done one, in not doing a great deal of documentation. 

Berner : Yes, I'm sorry. We were in a rush. I used to be going 

back and forth to my home in Westport and it would be one or 
two in the morning and I'd have listings spread all over the 
floor of the train -- it was just that way. 

Lee : Now Flo [Pessin] claims that there were a number of 

innovations with FOR TRANSIT which appeared again in later 
years -- like the parenthesizing technique [of determining 
hierarchy in expressions], the tabular method of analysis. 
Can you think of any others that she may have missed? Were 
there any that Hemmes [ii] and the rest of the group put into 
FOR TRANSIT? 

Berner : If there were, I couldn't remember them now because I 

wasn't that close. I'd walk around from person to person and 
see what they were doing, discuss it, help where I could, but 
mostly I was doing other things. 

Lee : You were managing the project to all intents and purposes? 

Berner: Yes. 


[ii] Hemmes did a piece of ingenious board wiring to permit a 
numeric 650 to read and punch alphanumeric characters -- 
Pessin. 
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Lee : Apart from the fact that you were going to get this job 

done in almost one-tenth of the time that the original 
FORTRAN had taken, you didn't do any optimization. 

Berner : That always seemed to me a mistake in the first FORTRAN. 

Not the optimization itself, but the fact that you couldn't 
turn it off. I made a survey after FORTRAN first got out, 
and it turned out that on the average people were compiling 
FORTRAN programs 50 times before they got it correct. 

Lee : So if in fact it was like the current PL/I, where you can 

turn the optimizer on and off, it would have been much 
better. But I don't think that John thought about that in 
those days -- but that wasn't his plan either — the whole 
purpose of the original FORTRAN was the optimization. 

Berner : And you can't fault them for that, because no one could 
predict during the design of the language that anyone would 
make that many mistakes in the syntax and its usage. We had 
no background and experience in that. 

Lee : One of the arguments was that you weren't going to make any 

mistakes when you were doing these things. So in many 
respects FOR TRANSIT was a quick and dirty implementation -- 
to get something going and to hell with what the resulting 
code was not going to be. 

Berner : It was to prove something. To prove you could move a 

language from one machine to another and to prove it was not 
just between two installations on the West Coast but in the 
IBM community. 

Lee : FOR TRANSIT depended so heavily on A1 Perlis' IT. If A1 

Perlis had not in fact finished producing his IT you would 
have been dead. 

Berner : Yes. 

Lee : Now John had some derogatory remarks about his relationship 

with A1 Perlis in the late FORTRAN days when Perlis was 
saying "I don't know why it is taking so long to do this, 
after all I wrote IT in a summer". So my impression is that 
there was no good relationship between John and Al, yet you 
had to have a good relationship because you were relying on 
IT. 

Berner : Not only had to have one, it never occurred [to us] not 

to have one. I was always friendly with Al [Perlis]; last 
time I saw him of course was the Programming Language 
Conference [HOPL] and the last time before that was in Munich 
at the Software Engineering Conference -- we've always gotten 
along great. 


Third Draft 


FORTRAN 25 


Robert Berner 


7 


Lee: Then any potential animosity that there was from the 

original group didn't carry over to your group. Flo also 
says that IT was changing, and even though you were trying to 
compile from FORTRAN to IT, the target was a moving target. 

Berner : Well, we had to make an arrangement with Perlis, that at 

a particular time we had to cut off and that was IT. (Pun 
intended. ) 

Lee: Was he [Perlis] in fact doing implementation or was he 

always like Charles Babbage always correcting and improving? 

Berner: Yes they did a lot of correcting. Well they had to, they 

were in a University atmosphere and they weren't charged with 
the production of any product. So obviously they were 
learning, and part of that went over into ALGOL. 

Lee: Was there any financial arrangement between IBM and Perlis 

over this? 


Berner : No, no, none at all. 

Lee : This was a free -- gratis 

achievement . 


for the glory of its 


Berner: Yes, the only credit Perlis ever got was his name on the 

first manual. 

Lee: So you had no leverage with his group to say "produce"! 

Berner : No, we had one copy and if he didn't give us an updated 

copy we'd go ahead with the one he had. He was very generous 
with it. 


Lee: Flo, for example, talked how FORTRAN was translated into IT 

and you had left to right scanning in FOR TRANSIT, but right 
to left scanning in IT. Did you put any pressure on Perlis 
to change IT, to update it, or change it to suit your needs? 

Berner : No, I think I was probably just grateful enough that we 

had it and we figured that somehow we could mask that out. 
But it turned out to be a hell of a masking problem. 

Lee: Really, then, these were two independent projects but 

working hand-in-hand, as opposed to one strongly influencing 
the other. 


-L : wasn t a joint team [effort]. We didn't send people 
to Carnegie and they didn't send any to New York to work 
together on this. It was entirely independent. 


Lee : In some respects you were 

have a "fail-back" plan? 


lucky that IT got out. 


Did you 
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Bemer: No, we had faith. 

Lee : It appears to me that not to have "Plan B" in case IT 

didn't get produced in a University was very dangerous. 

Bemer : In those days we didn't think about those kinds of 

things . 

Lee: Once you completed FOR TRANSIT -- Flo [iii] went to the 650 

FORTRAN [project] with Lynn Woo, but you and Dave Hemmes went 
to XTRAN. Was there anyone else with your team on XTRAN? 
What happened to Otto Alexander and Leroy May? 

Bemer: They went on to some different things [iv]. 

Lee : Leroy May went on to FORTRAN II with John, I believe. 

Bemer : Otto and Leroy left my supervision and I got a whole new 

bunch of people. By this time we had moved to 425 Park 
[Avenue]. Those were people like Roy Goldfinger, Julian 
Green and others. 

Lee : Those are names that are more related with COBOL and ALGOL 

than they are with FORTRAN. 

Bemer : I confess that as FORTRAN got going I kept looking at its 

limitations and there was a whole bunch of things that I 
wanted to change. It was at that time that Samelson and 
Bauer came tripsing through looking for a cooperative 
project, and I got very fired up about that. 

Lee : They had a paper in 1960 on this method of analyzing 

[ expressions ] . 

Bemer : No this was before that, this was probably in 1957, we 

got through with FOR TRANSIT in August '57. They came 
through and we started working on what became ALGOL ' 58 and I 
got very enthused about that because we had already been 
working on XTRAN. So when Samuelson and Bauer came around to 
see Backus and myself. . . 

Lee : Let us back off a moment -- there is dichotomy, when you 

talk about Samelson and Bauer, and Backus and Bemer -- are we 
talking about the corporate entities of Backus and Bemer 
within IBM? In other words were Samelson and Bauer coming to 
IBM, or were they coming to meet two scientists? 


[iii] I worked on XTRAN for while before the 650 project -- 
Pessin. 

[iv] Otto continued working on 650 projects and then moved to 
the 7070 FORTRAN project -- Pessin. 
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Berner : Two scientists, I guess. They had to have clearances to 

talk to us, but it was nothing that IBM figured out. They 
never thought about ALGOL as profit-making. Entrepreneurship 
on our part. 

Lee : Was it also in cooperation with John Carr and ACM? 

Berner : Oh y e s . 

Lee : Carr by this time had appointed John as the representative 

to the joint GAMM/ACM group. 

Berner : That came about after Samelson and Bauer made their tour. 

They had made a tour of the United States, and after they did 
that they wrote to John Carr. 

Lee : Inviting the cooperative effort? They were then coming to 

Backus and Berner looking for some cooperative activity to 
develop language further. Now John went over to the ALGOL 
project, which, from the point of view of looking at the 
history, almost looks like he went over completely. There 
were no other publications that came out of that group headed 
by Backus which refer to FORTRAN; everything is ALGOL. Was 
John working on anything else? 

Berner : Well yes, he had people working on FORTRAN III and IV. 

Lee : That is Nelson, Ziller and that group. 

Berner : But he himself had moved onto the next thing. 

Lee : He was deeply involved in the ALGOL side of things. 

Berner : I couldn't tell you what he was thinking about -- he'd 

have to tell you what he had started thinking about by that 
time . 

Lee : I think we got that at HOPL. He talks about that period. 

What I'm thinking about is that Bob Berner is now stuck with 
FORTRAN. If I remember correctly you were a "language 
control person" or had some title like that. 

Berner : Well, considerably later I became Director of Programming 

Standards, that was after the X3 business started. 

Lee : That is 1960 though -- but there was a period there, for 

example reading your papers [in the Smithsonian] where it 
appears that Berner was the one that was controlling of the 
language and not doing any development. 

Berner : That's right. 
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Lee: Very clearly, I remember reading a letter [in the SHARE -- 

Verzuh files] that said: "Don't ask Berner what we ought to be 
doing, it is what we are doing". I forgot who it was from 
now, but the comment was along those lines. 

Berner : That may have been Barry Gordon about Commercial 

Translator because Tom Gians and I and several other people 
were working on the language design for Commercial 
Translator. But when it went to Barry Gordon for production 
they changed a lot of things -- and to my mind for the worse. 

Lee: Let me come back and talk about this marriage, with this 

almost illicit relationship between FORTRAN and ALGOL. Now 
XTRAN was sitting in the middle of this, so to speak. Tell 
me about that. 

Berner : Well that was Hemmes and myself, trying to carry on where 

we felt it might go after FORTRAN. We were on the same floor 
with Backus, so we knew about ALGOL and what they were doing. 
But still they were in the area of what to do for a machine 
the compiler construction. We were very much more 
thinking of the ease of expressing a problem. 

Lee : Did you have in mind at that time that you would convert 

FORTRAN into ALGOL, that that was going to be the natural 
direction to take, or did you know one had to die? 

Berner : Well you know, having had experience with FORTRAN and IT, 
which was a difficult marriage, I figured I could do the same 
thing again. 

Lee : Now in the 1961 paper to the British Computer Society you 

talk about having had a translator written from FORTRAN to 
ALGOL -- was that XTRAN? 

Berner : Yes, but by that time we had given up the name XTRAN when 

it became obvious that there was international work going on. 
We would have gone ahead if there hadn't been international 
work on ALGOL. 

Lee : So XTRAN was, to all intents and purposes, 

Berner: IBM's beginning of ALGOL. 

Lee : It was to ALGOL what FOR TRANSIT was to FORTRAN. Was that 

a back pocket operation as well, or was this IBM supported? 

Berner : All the things I did were supported by IBM. It is just 
that by that time they hadn't grown that much, and I was 
still working for [John] McPherson who had every confidence 
in me -- with what I was coming up with. 
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Lee: So it was not part of a long-range plan -- this was a bump 

on the side that might lead to something else. 

Berner : Yes. 

Lee : About this time, 1959,60,61, is the period when reading 

your papers [in the Smithsonian] I see this dichotomy between 
two people. What I call the Bob Berner, the Corporate person, 
and the Bob Berner, the ACM member. 

Berner : I didn't have too much choice about that in IBM. On 

certain stages when one was speaking officially for the 
company you had to do it. 

Lee : But I even see it in some of your internal stuff -- those 

papers that would not be [seen] outside. For example you did 
a tour of Europe and after you came back your trip report 
said -- "Unless we provide ALGOL to these Europeans, we are 
not going to sell machines in Europe" but your memo also goes 
on to say "we ought to be selling them FORTRAN as well and we 
ought to encourage them to use FORTRAN." On the other hand I 
saw letters externally which seemed very much to be 
supporting the ALGOL line 

Berner: Yes. 


Lee : 

...and the famous quotation, I guess, is that "FORTRAN has 
run its course and we don't want to perpetuate it." Now that 
[statement] caused you problems ... 

Berner: Yes it did. 


Lee : I believe that was 1960 September 26-30 when you gave the 

talk and 1961 when it was published. 

Berner : Yes, 1961 when it was published, and in 1962 I was sent 

to Research and a month after that I was at Sperry-Rand. 

Lee : Were you sent to Research to get you out of the customer's 

way? 

Berner : Yes. 

Lee : That very same period of 1962 is also the period when John 

Carr was accusing IBM of sabotaging ALGOL. 

Berner : That is correct. 

Lee : That is [recorded] in your papers -- did you instigate 

that? 
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Bemer : No, it was the ALGOL people who were sabotaging ALGOL -- 

all that stuff is in there [at the Smithsonian] with Wegstein 
and the maintenance committee. As I said. Van Wijngaarden 
had a flash of perception, that is in one of my reports, that 
IBM could not promise customers a stable language — if it 
was out of their control. They had to be participants 

Lee: The same as with the DoD and Ada today. And so as long as 

IBM was not in there controlling ... 

Berner: No, it was more than that, it was the frivolity of the 

thing. Any person who had worked "with" on ALGOL had as much 
voice as IBM did, and that was very unreasonable. The whole 
input/output business — what were we going to do about that? 

Lee: But that is really no different from the problems we are 

going through today in many other situations -- in many other 
languages. I guess we haven't learned to live with it any 
better today than you did then. So your support of ALGOL 
lost you your job! 

Berner: No, not alone. It was also my support of ASCII that lost 

me my job! 


[End of First Side] 

Lee: So it wasn't only ALGOL -- which I was concluding from your 

papers at the Smithsonian -- but you claim it was ASCII, too. 

Berner : Well that was the official story, a quote that I got from 

Bill Andrus, who died a year or so ago. Bill said he finally 
had to send me up there because Learson "thought I was going 
to give the store away." That I was cooperating too much with 
X3 and other outside efforts, and that wasn't in Learson' s 
plan. 

Lee : And that plan was to be independent? 

Berner: No, to move it all under the IBM umbrella, and not to 

cooperate in any way. 

Lej3: But that is also the period [61, 62 or somewhere about 

then] when IBM was broken up because of a monopolistic 
situation that resulted in IBM dropping card production and 
manufacturing. 

Bemer : As matter of fact it was Learson. According to Fred 

Brooks, the ASCII printer and card punch were not ready for 
the 3 60, so Learson ordered the drop off on that and forced 
EBCDIC all the way. 

Lee: I remember a suggestion that the 360 was going to be an 

ASCII-based system. 
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Bemer : Yes it had the "P-bit" to permit that; but they didn't 

make any software for it which is what you would have done if 
EBCDIC had not won - so that was the end of it [ASCII]. 

Lee : Your own progression then was FORTRAN, to the love for 

ALGOL, followed by the ASCII activity. 

Bemer : Right, and yet at the same time in COMTRAN , I wanted to 

bring both sets of processing together. 

Lee : Now Flo [Pessin] was involved in COMTRAN wasn't she? 


Bemer : Yes. 

Lee : I didn't talk to Flo much about that, but she seemed to 

think that was a foregone failure to start off with because 
of COBOL -- COBOL totally superseded that. 

Bemer : But IBM didn't want it that way. It [the demise of 

COMTRAN] might not have happened so late if it hadn't been 
for Dick Talmadge's version (of Commercial Translator) for 
the 709, which was pretty good. 

Lee : But not .salable because of the machine on which it was 

implemented. 

Bemer : No, a lot of customers stuck with it (Commercial 

Translator) way past the COBOL beginning, but finally IBM did 
give up and had to admit that they had to have COBOL. 

Lee : Let me come back to the ALGOL-FORTRAN concept. XTRAN 

really didn't fly. 

Bemer : No, it was our design, but as a name we didn't carry it 

forth because at that time IBM was perfectly willing to 

cooperate with the ALGOL investigation. We built a 
processor, at least Julian Green did that mostly, with Bob 
Shapiro and some other guys. 

Lee : But Julian only built a partial processor -- I remember 

reading SHARE minutes on that, where there was some very 

delicate wordsmithing going on between A1 Harmon, Julian 
Green and others about whether this was really an ALGOL 

compiler or merely an experimental production. . . 

Bemer : Well, it wasn't really all that experimental, but Harmon 

made it seem as though it was more experimental than it 

really was. He didn't want to upset any apple carts then. 

Lee : But there also was no commitment being made [to customers]. 

Then SHARE announced a temporary hold on the support of 
ALGOL . 

Bemer : Yes. It was a very firm hold, temporary or not. 
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Lee : But it was still announced as a temporary hold. Now did 

IBM take advantage of that to say "to hell with it"? It is 
not clear in my reading which tail was wagging which dog. 

Bemer : Well they [IBM] never stopped the work on ALGOL, we kept 

on going with Julian [Green] participating in ALGOL 60 group. 
When there was the IFIP meeting in Feldafing [Germany], 1962 
March, I had the IBM manual for ALGOL in my briefcase with me 
at that time . 

Lee : So there was a set of working manuals for ALGOL! 

Bemer : Oh y e s ! 

Lee : Was it a typeset manual? 

Bemer : Not typeset, it was a draft manual. The original authors 

of ALGOL thought that adding 3 letters "ity" to "author" 
meant that the fact of publishing conveyed control. So I 

asked if IBM publishing that ALGOL manual would also convey 

as much, or more, control. The fact that IBM made something 
like this -- would this become a standard by virture of their 
authority? And they didn't like that -- they wanted the 

authority to be with the original 13, which was not working 
worth a damn. So then I wrote my memo to Ike Auerbach to 
advise him that IFIP should assume authority for ALGOL. 

Lee : One of the other people who was critical at that time was 

Mort Bernstein, who accused the ALGOL Committee of not 

fulfilling its charter -- the same way as John McCarthy 
accused them of overstepping their charter at HOPL. Mort 
seems to claim that they went too far, that they were given 
the job of just producing a nice simple little language and 
they blew it. Reading the SHARE papers on that, Mort seems 
to have overstepped his bounds because that was Bernstein' s 
opinion and not SHARE'S opinion of what was going on. Later 
on Mort had to rescind what he said, but eventually SHARE 
came around and said "you're right." 

Bemer : At that stage of programming language development there 

was no comprehension of the dangers you could get by always 
twiddling a language. There was just the excitement of 
developing a new concept. That even went on in the ALGOL X 
and Y work in 1968. 

Lee : The history of the SHARE ALGOL committee is interesting. 

Frank Engel was chairman for a while and that committee did 
nothing -- they did very little and there was a suggestion of 
apathy on the part of the USA. That committee was disbanded; 
a new committee was put in place with Mort Bernstein as 
chairman. And Mort wrote the famous letter saying you're not 
doing the job properly. Were you involved in any of that at 
all? 
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Bemer: Not as much as that. I was back at IBM trying to get it 

done and working as best I could with IFIP to get control 
over there. 

Lee : From your travel log you seemed to be oscillating backwards 

and forwards between the two [sides of the Atlantic] almost 
more than John [Backus]. You were doing the implementation 
but John was only a member of the committee. 

Bemer : That's right. As a matter of fact that's the same 

relationship in which I stood with the Commercial Translator 
people . 

Lee : By that time, then, your job was less of a direct 

management of the project; it sounds more like a liaison duty 
-- or were you doing both? 

Bemer: Well, I stepped aside into character sets at that time 
but I became manager of language standards. The reason I got 
started on that was Bob Evans was making a successor to the 
650 called the 660, which was going to take over what the 705 
did, and I kept telling him for three months, you can't have 
a nineteen and a half on the 650, which is where the tape 
mark had to collate. By that time I had started studying 
character sets with Frank Williams and Howard Smith, and we 
found out that IBM alone had nine different coded character 
sets . 

Lee : Now ASCII came out of the State Department didn't it [for 

the Kennedy Washington-Moscow hot-line]? 

Bemer : No, ASCII and the 8-bit code originated right in my 

group, with Howard Smith and Frank Williams. Howard wrote a 
paper on the notational efficiency for the 8-bit code. I 
started working with SHARE and GUIDE on the thing. I had 
made up this set and they didn't like it very much so I had a 
big meeting in New York with all the people. We went through 
it and finally got through their committees and found that my 
stuff was the same as I originally had it. And that's why 
the reverse slash is in there. 

Lee : Tell me about that. 

Bemer : Well the reverse slash and the slash can make the "and" 
and the "or" of early ALGOL out of \ and /. 

Lee : -- making your "and" and "or" from composite characters. 

Bemer : Right. 

Lee : Let me go back again. You went through FOR TRANSIT and you 

went through XTRAN and you had perpetuated the cascading idea 
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when did you decide not to go any further? Why was 
cascading dropped? 

Berner : Because of the ALGOL-FORTRAN flap in SHARE, and the flap 

between IBM and the ALGOL maintenance committee. I was 
trying to get the two together; I kept saying that you could 
bring them together and where there were incompatibilities 
you could hide it. The point is that you have to go back to 
the more reasonable way of expressing it. ALGOL had much 
better constructs, therefore let's go to them. Let’s put a 
FORTRAN processor under there and tap down into it. When it 
blew up into such a big fight, I got out of it. 

Lee : Flo [Pessin] made the comment that economically it is 

infeasible to continue to go that route. 

Berner : No it isn't, it could have been for the 650 but take some 

of the modern machines with so many mips today that it 
doesn't make a doggone bit of difference [v] . You can see 
that compared to other inefficiencies... 

[Tape jammed]. 


[v] Pessin: The interposition of one or more additional 
processes can readily be detected by a user at a terminal. 
Furthermore, the dependencies created by cascading are 
undesirable: (1) the quality of your product is gated by the 
quality of the processors on which it rides, (2) yours 
product's stability depends on the continued stability of the 
interfaces with those other products and (3) your ability to 
enhance your product is inhibited by the functional 
capabilities (or lack thereof) of the processors to which it 
cascades . 

Finally, and most cogent, cascading is unnecessary. A 
translator is a translator is a translator . . . That is to 
say, whether the task is to go from source language A to 
target language B or to target language C, the quality of the 
effort is essentially the same. 
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Toward Standardized 
Video Terminals 

ANSI X3.64 Device Control 

A set of codes that promises to alleviate incompatibility 


The video screen and the keyboard 
are the means by which most of us 
communicate with our computers, 
and they probably will remain the 
mod efficient vehicles of human/ 
cc puter interaction for years to 
come. A video-display terminal is a 
neat package containing both screen 
and keyboard, and even though 
many of today's personal computers 
contain integral keyboard and video- 
display circuits, discrete terminals are 
still the user workstation of choice in 
most large and many small computer 
s; ■ ems. And most of the terminal 
operation principles involved apply 
also to the computers that integrate 
the functions. 

Although conceptually and physi- 
cally convenient, video-display ter- 
minals have suffered from software 
incompatibility. But a direct attack on 
this problem has been mounted by 
the development of a standardized 
method of controlling a terminal's 
functions. In this article I will 
describe the weapon of attack: the 
ANSI X3.64 standard. 

Why a Standard is Needed 

What happens when you sit down 
at a video-display terminal and hit 


Mark L. Siegel 
Televideo Systems Inc. 

the Return key? The cursor on the 
screen responds by moving to the left 
edge of the screen (and sometimes 
also down one line). You get the im- 
pression that the key directly controls 
the cursor's movement. But it 
doesn't. The depression of the key is 
sensed by the terminal's keyboard- 
control circuitry, which generates a 
unique binary code. The terminal's 
display-control hardware receives 
this code, interprets it, and recog- 
nizes it as a Return character; the 
hardware then moves the cursor's 
position accordingly. Or it can be 
even more complex: the key depres- 
sion can be transmitted to a remote 
computer, where a program is run- 
ning that analyzes the Return-key 
code and transmits back some dif- 
ferent code to modify the screen con- 
tents in a way appropriate to some 
particular application. 

The interface between a terminal 
and a computer must take account of 
compatibility on both the electrical 
level and the code (or logic) level. For 
specifying alphanumeric and, other 
printable or displayable characters, all 
peripheral devices found in personal 
computer systems use the set of 
codes known as ASCII, the American 


National Standard Code for Informa- 
tion Interchange, shown in table 1. 
(ASCH's formal name is ANSI X3.4- 
1977; the abbreviation is pronounced 
"ass-key.") Some departures from the 
ASCII standard occasionally do occur 
in the character set, in some seldom- 
used characters, but differences 
typically emerge in how each manu- 
facturer defines the codes for control 
functions. 

Designers of terminals (and other 
peripheral devices) must choose a set 
of codes to indicate not only which 
alphanumeric characters are to be 
displayed or printed, but also to ini- 
tiate various control functions: to 
move cursors, change colors, or scroE 
the display. Most video terminals use 
similar hardware to control the dis- 
play. What may be different are the 
binary codes that have been chosen 
to represent the particular functions. 
Thus, even if one terminal's circuitry 
is almost identical to another's, if the 
control codes are different, the two 
terminals cannot be used with the 
same software. 

ASCn was developed with the ac- 
tivities common to simple printers 
and teletypewriter terminals in mind. 
However, the variety of computer pe- 
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Table 1: The American National Standard Code for Information Interchange (ASCII). This table is arranged to allow the character 
positions to be specified in column/rcrw character notation, where the column number is the decimal equivalent of bits b7 through b5 
in a 7-bit environment (or bits a8 through a5 in an 8-bit environment), and the row number is the decimal equivalent of bits b4 through 
bl or bits ai through al, with b7 (or a8) the most significant bit in the character. Bit combinations are represented by the notation "col- 
umn m, row n" or alternatively as "mini', where m and n are the decimal column and row numbers, respectively. For instance, the 
capital letter A is the character in position 4/1. 


ripherals has grown considerably, 
and the number of different func- 
tions has also grown. The 32 control 
characters specified by the X3.4 ASCII 
standard became inadequate some 
years ago for providing peripheral 
control for the growing crop of new 
peripherals and their functions. 

Many applications today demand 
sophisticated editing capability in 
video terminals, which therefore 
must have versatile screen-control 
functions. Users wish to be able to 
quickly move the active position (and 
its cursor) to any point on the display 
screen. Also, they need the flexibil- 
ity for inserting and deleting single 
characters, strings of characters, or 
entire lines. These control functions 
go well beyond the scope of the 
ASCII standard. 

When no control-function standard 
existed, designers of peripherals 
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created their own control sequences 
using whatever combinations of 
ASCII control characters seemed 
handy. It was not uncommon, espe- 
cially in devices with many functions, 
for designers to exhaust the existing 
set of control codes. They had to 
resort to using longer combinations 
or sequences of control characters. 
Because there were no common 
guidelines for creating these se- 
quences, no two manufacturers used 
the same ones for the same 
purposes. 

As a result, a programmer develop- 
ing application software for a com- 
puter system always had to find out 
the specific codes used by the par- 
ticular peripheral devices attached to 
the computer in order to write the 
device-driver portions of the soft- 
ware. This part of the program was 
therefore device-specific and would 


work properly with only that par- 
ticular device or another that hap- 
pened to employ the same control 
codes. 

Application programs written to be 
used from a video terminal had to 
contain code to match that particular 
terminal's control sequences— often 
rendering the application programs 
useless on a system with a different 
terminal. 

For vendors that design and manu- 
facture all the components of their 
computer systems, use of proprietary 
terminal-control character sequences 
posed few problems. But vendors 
that assembled systems by purchas- 
ing processors, terminals, and pe- 
ripherals from different manufac- 
turers regarded the proliferation of 
control protocols as a plague, as did 
a group of manufacturers that sold 
terminals to those vendors. Expecting 
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We make C easy... 



and work! 

Eco-C compiler... we've 
got it all. 

Whether you're a seasoned professional or 
just getting' started in C, the Ecosoft C com- 


piler has everything you'll ever need. 
COMPLETENESS: 

Our Eco-C compiler is a complete im- 
plementation of C and supports all operators 
and data types (including long, float and 
double). 

EFFICIENCY: 

The compiler generates extremely efficient 
Z80 code using Zilog's mnemonics. On the 
benchmarks tested, typically we finished 
either first or second using substantially less 
generated code. 

PORTABILITY: 

The Eco-C library contains over 100 func- 
tions that are UNIX V7 compatible, and in- 
cludes a complete transcendental package. 
Programs developed with the Eco-C compiler 
can oe moved to virtually any system with 
little or no change. 

EASE OF USE: 

The Eco-C compiler includes Microsoft's 
MACRO 80 assembler, linker, library 
manager and supporting documentation. The 
assembler (M80) generates industry-standard 
REL file output. The linker (L80) is fast and 
uses only the functions you request in the 
program'. Program development is a snap. 

Tne user's manual is clear, concise and full 
of useful information. For those of you just 
getting started with C, we also include a 
copy of the C Programming Guide (Que). 

This B. Dalton Best Seller has been adopted 
by a number of leading universities around 
tne countrv and is included with each com- 
piler. The book is designed to help you learn 
C fromjthe ground up. We ought to 
know..Twe wrote the book. 

We've made the compiler easy to work 
with for the professional and beginner alike. 
Most error messages, for example, tell you in 
English (not just a number) the line number 
ana character position of the. error, what was 
expected and a page reference to the Guide 
to consult for help if you need it. 

PRICE: 

We saved the best for last; we've cut the 
price by $100.00. Now you can buy the Eco-C 
compiler for only $250.00 (MACRO 80 and 
the book alone are worth 5218.00!). Shop 
around and we think you agree that the Eco- 
C compiler is the best value available. 

The Eco-C compiler requires a Z80 CPU, 
CP/M, 54K of free memory and about 240K of 
disk space (one or two dnves). An IBM-PC 
version will be available in the first quarter of 
84. To order your Eco-C compiler, call or 
write. m 

Ecosoft Inc. I VgL- 

Mm—MJ— P-O. Box 68602 
M M M Indianapolis, IN 46268 LmJ 

icaiaTr^S. (317) 255-6476 

TRADEMARKS: 

Eco-C (Eco«oft). MACRO 80 (Microsoft), CP/M (Digital Research) J 
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to benefit greatly from the existence 
of a standard set of control se- 
quences, these independent periph- 
eral-device manufacturers became 
conspicuously interested during the 
late 1960s and early 1970s in the at- 
tempt by ANSI, the American Na- 
tional Standards Institute, to develop 
an American National Standard for 
device-control character sequences to 
be used together with the printing- 
character ASCII standard. 

Development of the Standard 

One surprise about American Na- 
tional Standards is that their use is 
largely voluntary. ANSI cannot of 
itself force any manufacturer to pro- 
duce products conforming to them, 
but ANSI standards carry consider- 
able weight because of ANSI's fair 
and methodical committee process 
and the organization's reputation for 
representing nearly all interested 
parties. 

A key part of X3.64 is 
the control-sequence 
introducer. 

The computer industry works 
through ANSI's Committee X3 on In- 
formation Processing Systems, which 
includes representatives of computer 
manufacturers (IBM, Sperry Univac, 
Digital Equipment, etc.), user groups 
and government agencies (General 
Services Administration, Air Trans- 
port Association, United States 
Department of Defense, National 
Bureau of Standards), and trade and 
professional associations (Institute of 
Electrical and Electronics Engineers, 
Association for Computing Ma- 
chinery, etc.). All American National 
Standards pertaining to computers 
pass through committee X3. The 
standards bear numbers showing 
their committee origin, their se- 
quence of adoption, and the year 
they were approved — like X3.64-1979. 
(For more detailed information, see 
reference 4.) 

The X3 committee assigned the 
work of developing the device- 
control extensions to ASCII to the 
X3L2 Technical Subcommittee on 


Codes and Character Sets. The X3L2 
committee was directed to devise a 
standard that could meet the foresee- 
able needs for input/output control of 
one entire class of peripheral devices, 
the ones that create images in two 
dimensions by character-oriented 
means. This class includes video 
display terminals, character and 
printers, and microfilm output 
printers. The standard was intended : 
to be useful in a wide variety of ap-'f 
plications, including on-line form fill-J 
ing by templates, typesetting, and-' 
word processing. 

After the technical subcommittee! 
finished its methodical process ini 
1977, and after the higher-level AN S3 
committees had voted approval iril 
1979, ANSI published the document 
called ANSI X3.64-1979: Additional* 
Controls for Use with the American Na-t 
tional Standard Code for Information^ 
Interchange. jfl 

The X3.64-1979 standard was fo|M 
mulated in compliance with the praj8 
cedures for extending ASCII set fortfa 
in a standard called ANSI X3.41-1974M 
Code-Extension Techniques for Use witM 
the 7-Bit Coded Character Set oM 
American National Standard Code for Irak 
formation Interchange. (The later data 
of the X3.4-1977 standard means thafl 
ASCII has been revised. American 
National Standards expire after fnfl 
years; when that time has passe J 
they are either revised, reaffirmed,^® 
left for dead.) The Internationa 
Organization for Standardization* 
(ISO) later adopted a similar standagp 
called ISO DP6429: Additional ConfiM 
Functions for Use with Character-ImafijM 
ing Devices— essentially a superset^® 
X3.64-1979. 

What the Standard Does |j| 

The X3.64-1979 standard was nou9 
tended to define the exact electrons 
features or characteristics of any p«B 
ticular peripheral device. In fact, th* 
technical subcommittee did not afl* 
ticipate that any single device wouj* 
incorporate all of the controls defii^B 
by the standard. . .sTls® 

What the standard does is speaM 
control sequences for a great numb® 
of control functions, almost all tha® 
you would find in commercial com® 
puter equipment. The X3.64 do(3M 
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merit describes 97 possible functions; 
the ones of interest to users of video 
terminals include changing the cur- 
sor and active position, editing lines, 
and scrolling. 

All of the characters that appear in 
ANSI X3.64 control sequences are 
ASCII characters. These are used as 
an alphabet for building a set of con- 
trol "words" that describe control 
functions. 

One key part of X3.64 is the control- 
sequence introducer or CSI— a sequence 
of characters that unmistakably iden- 
tifies the characters that follow as 
parts of a command to invoke one of 
the control functions of the video ter- 
minal (or other device). The regular 
CSI in X3.64 for the 7-bit ASCII char- 
acter set consists simply of two ASCII 
characters; the Escape control char- 
acter (decimal 27) and the left-bracket 
("[") character. (There are also an as 
yet >eldom-used 8-bit CSI and corre- 
sponding sequences.) In addition, 
some of the X3.64 functions are intro- 
duced by a single Escape character. 

The characters that follow the CSI 
prefix in an X3.64 sequence specify 
the function that is to occur and 
supply numeric parameters that are 
needed by many functions. The char- 
a ’ters following the CSI are either in- 
i-mediate or final. In most cases any 
intermediate characters after the CSI 
supply the parameters, while the 
final character specifies the functions 
to occur, but sometimes intermediate 
characters assist in specifying the 
function. There is no limit to the 
number of intermediate characters. It 
is possible to build compound con- 
- f sequences; a single CSI prefix 
can be followed by a string of param- 
eters and' function-specifying charac- 
ters, with the codes for each function, 
separated by semicolons, used as 
delimiters. 

Only printable characters are used 
in X3.64 sequences following the CSI; 
among other things, this allows the 
Vstem to use the X-on and X-off 
(Control-S and Control-Q) nonprint- 
ing characters to start and stop the 
flow of data between the host com- 
puter and the terminal with no 
chance that the nonprinting charac- 
ters will be mistaken by the terminal 
for function commands. 


The major control functions avail- 
able in X3.64 are listed in table 2. Each 
function is identified by both a name 
and a short mnemonic; the table is 
in alphabetical order by mnemonic. 

The functions are affected by 
various modes that can be set (turned 
on) and reset (turned off) by means 
of the Select Mode and Reset Mode 
functions. A list of modes and the 
parameters to change them is given 
in table 3. The Select Mode and Reset 
Mode functions can also be used 
with reserved-private parameters in 
a specific video-terminal design to 
control modes and functions that 
exist only in that particular terminal. 

A Function Example 

Of all the command functions, the 
cursor controls are perhaps the most 
familiar, and of these the most ver- 
satile is the Cursor Position (CUP) se- 
quence, which allows the cursor to 
be placed at any arbitrary position on 
the display screen. The format of the 
CUP, from table 2, is 

Esc [ Pn ; Pn H 

The sequence begins with the 
ASCII Escape character (here abbre- 
viated to "Esc") followed by the left 
bracket. These two together form the 
7-bit control-sequence introducer. 
After the CSI comes a parameter, de- 
noted here by Pn. In an actual com- 
mand, this variable would be re- 
placed by one or more ASCII char- 
acters for numeric digits, positions 
3/0 through 3/9 in table 1. The first 
parameter is terminated by a semi- 
colon, which leads to the second pa- 
rameter— again, one or more ASCII 
characters representing digits. The 
"H" at the end of the command both 
terminates the second numeric pa- 
rameter and specifies that the com- 
mand is the CUP. 

For instance, consider the se- 
quence 

Esc [ 17 ; 45 H 

This sequence instructs the ter- 
minal to move the active position 
(and the cursor that indicates it) to 
the seventeenth line from the top of 
the screen and to the fortv-fifth col- 
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Mnemonic Name 

Sequence 

Default 

Value 

Type 
or Mode 

APC 

Application Prog Command 

Esc Fe 


Delimiter 

CBT 

Cursor Backward Tab 

Esc [ Pn Z 

1 

EdF 

CCH 

Cancel Prev Character 

Esc T 



CHA 

Cursor Horizontal Absolute 

Esc [ Pn G 

1 

EdF 

CHT 

Cursor Horizontal Tab 

Esc [ Pn 1 

1 

EdF 

CNL 

Cursor Next Line 

Esc [ Pn E 

1 

EdF 

CPL 

Cursor Preceding Line 

Esc [ Pn F 

1 

EdF 

CPR 

Cursor Position Report 

Esc [ Pn ; Pn R 

1, 1 


CSI 

Control Sequence Intro 

Esc [ 


Introducer 

CTC 

Cursor Tab Control 

Esc [ Ps W 

0 

EdF 

CUB 

Cursor Backward 

Esc [ Pn D 

1 

EdF 

CUD 

Cursor Down 

Esc [ Pn B 

1 

EdF 

CUF 

Cursor Forward 

Esc [ Pn C 

1 

EdF 

CUP 

Cursor Position 

Esc [ Pn ; PnH 

1, 1 

EdF 

CUU 

Cursor Up 

Esc [ Pn A 

1 

EdF 

CVT 

Cursor Vertical Tab 

Esc [ Pn Y 


EdF 

DA 

Device Attributes 

Esc [ Pn c 

0 


DAQ 

Define Area Qualification 

Esc [ Ps o 

0 


DCH 

Delete Character 

Esc [ Pn P 

1 

EdF 

DCS 

Device Control String 

Esc P 


Delimiter 

DL 

Delete Line 

Esc [ Pn M 

1 

EdF 

DMI 

Disable Manual Input 

Esc\ 


Fs 

DSR 

Device Status Report 

Esc [ Ps n 

0 


EA 

Erase in Area 

Esc [ Ps 0 

0 

EdF 

ECH 

Erase Character 

Esc [ Pn X 

1 

EdF 

ED 

Erase in Display 

Esc [ Ps J 

0 

EdF 

EF 

Erase in Field 

Esc [ Ps N 

0 

EdF 

EL 

Erase in Line 

Esc [ Ps K 

0 

EdF 

EMI 

Enable Manual Input 

Esc b 


Fs 

EPA 

End of Protected Area 

Esc W 


' £ 

ESA 

End of Selected Area 

Esc G 



FNT 

Font Selection 

Esc [Pn . Pn Soace D 

0, 0 

FE ■ I 

GSM 

Graphic Size Modify 

Esc [Pn : Pn Space B 

100, 100 

FE 

GSS 

Graphic Size Selection 

Esc [ Pn Space C 

none 

■ FE 

HPA 

Horz Position Absolute 

Esc [ Pn ' 

1 

FE 

HPR 

Horz Position Relative 

Esc [ Pn a 

1 

FE 

HTJ 

Horz Tab w/Justification 

Esc i 


FE 

HIS 

Horizontal Tab Set 

Esc H 


FE 1 

HVP 

Horz & Vertical Position 

Esc [Pn \ Pn: 

1, 1 

FE 

ICH 

Insert Character 

Esc [ Pn @ 

1 

EdF ■ | 

IL 

Insert Line 

Esc [ Pn L 

1 

EdF 

IND 

Index 

Esc D 


FE i 

INT 

Interrupt 

Esc a 


Fs 

JFY 

Justify 

Esc [ Ps ; ... ; Ps Space F 

0 

FE 

MC 

Media Copy 

Esc [ Ps i 

0 

■ I 

MW 

Message Waiting 

Esc U 


I 

NEL 

Next Line 

Esc E 


FE il 

NP 

Next Page 

Esc [ Pn U 

1 

EdF k 1 

OSC 

Operating System Command 

Esc ] 


Delimiter m 

PLD 

Partial Line Down 

Esc K 


FE ■ ij 

PLU 

Partial Line Up 

Esc L 


FE 

PM 

Privacy Message 

Esc “ 


Delimiter ' 

PP 

Preceding Page 

Esc [ Pn V 

1 

EdF 

PU1 

Private Use 1 

Esc Q 


. 

PU2 

Private Use 2 

Esc R 


3 

QUAD Typographic Quadding 

Esc [ Ps Space H 

0 

FE \ 

REP 

Repeat Char or Control 

Esc [ Pn b 

1 

~ 3 

Rl 

Reverse Index 

Esc M 


FE 

RIS 

Reset to Initial State 

Esc c 


Fs - 1 

RM 

Reset Mode 

Esc [ Ps 1 

none 

. 

SD 

Scroll Down 

Esc [ Pn T 

i 

EdF 

SEM 

Select Edit Extent Mode 

Esc [ Ps Q 

0 


SGR 

Select Graphic Rendition 

Esc [ Ps m 

0 

FE 

SL 

Scroll Left 

Esc [ Pn Space @ 

1 

EdF 

SM 

Select Mode 

Esc [ Ps h 

none 


SPA 

Start of Protected Area 

Esc V 


• 

'-A 

SPI 

Spacing Increment 

Esc [Pn ; Pn Space G 

none 

FE 

SR 

Scroll Right 

Esc [ Pn Space A 

i 

EdF < 

SS2 

Single Shift 2 (G2 set) 

Esc N 


Introducer 

SS3 

Single Shift 3 (G3 set) 

Esc 0 


Introducer 

Table 2: The 7-bit device<ontrol codes in American National Standard X3.64-1979. A 

given peripheral device may not respond to all codes, but most ANSI-compatible video 

terminals work with a subset of the most popular functions. 




Table 2 continued on page 37 3 
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ault 

Type 

je 

or Mode 



Table 2 continued: 


100 


FE 

EdF 

Delimiter 

FE 

FE 

Delimiter 

EdF 


FE 


EdF 


FE 

EdF 

Introducer 

Introducer 


lard 164-1979. A 
'•I- compatible video 


SSA 

Start of Selected Area 

Esc F 



ST 

String Terminator 

Esc\ 


Delimiter 

STS 

Set Transmit State 

Esc S 



SU 

Scroll Up 

Esc [ Pn S 

1 

EdF 

TBC 

Tab Clear 

Esc [ Ps g 

0 

FE 

TSS 

Thin Space Specification 

Esc [ Pn Space E 

none 

FE 

VPA 

Vert Position Absolute 

Esc [ Pn d 

1 

FE 

VPR 

Vert Position Relative 

Esc ( Pn e 

1 

FE 

VTS 

Vertical Tabulation Set 

Esc J 


FE 


Abbreviations: 

EdF editor function 

FE format effector 

Gs is a graphic character appearing in strings (Gs from 2/0 to 7/14) 

Ce is a control represented as a single bit combination in the Cl set of controls in an 

8-bit character set 

Fe is a Final character of a 2-character Escape sequence that has an equivalent 
representation in an 8-bit environment as a Ce (Fe from 4/0 to 5/15) 

■ is a P' nal character of a 2-character Escape sequence that is standardized interna- 

tionally with identical representation in 7-bit and 8-bit environments and is indepen- 
dent of the currently designated CO and Cl control sets (Fs from 6/0 to 7/14) 

Pn is a numeric parameter in a control sequence, a string of zero or more characters 
from 3/0 to 3/9 

Ps is a variable number of selective parameters in a control sequence with each selec- 
tive parameter separated from the other by the code 3/11 (which usually represents 
a semicolon); Ps from 3/0 to 3/9 and 3/11 




Parameter 

Mode 


Character 

Mnemonic 

Mode Function 

.*0 


an error condition 

J/1 

GATM 

guarded-area transfer mode 

3/2 

KAM 

keyboard action mode 

3/3 

CRM 

control representation mode 

3/4 

IRM 

insertion/replacement mode 

3/5 

SRTM 

status-reporting transfer mode 

3/6 

ERM 

erasure mode 

3/7 

VEM 

vertical editing mode 

3/8 


reserved for future standardization 

3/9 


reserved for future standardization 

3/10 


reserved separator for parameters 

1 1 


standard separator for parameters 

i 2 


reserved for private (experimental) use 

3/13 


reserved for private (experimental) use 

3/14 


reserved for private (experimental) use 

3/15 


reserved for private (experimental) use 

3/1 3/0 

HEM 

horizontal editing mode 

3/1 3/1 

PUM 

positioning unit mode 

3/1 3/2 

SRM 

send/receive mode 

3/1 3/3 

FEAM 

format effector action mode 

3/1 3/4 

FETM 

format effector transfer mode 

3/1 3/5 

MATM 

multiple area transfer mode 

3/1 3/6 

TTM 

transfer termination mode 

'/I 3/7 

SATM 

selected area transfer mode 

1 3/8 

TSM 

tabulation stop mode 

or 1 3/9 

EBM 

editing boundary mode 

3/ 1 3/.1 u 


reserved separator for parameters 

3/1 3/1 i 


standard separator for parameters 

3/1 3/12 


error condition— unspecified recovery 

3/1 3/13 


error condition— unspecified recovery 

3/1 3/14 


error condition— unspecified recovery 

3/1 3/15 

LNM 

error condition — unspecified recovery 

3/2 3/0 

3/2 3/1 

line-feed/new-line mode (not in ISO DP6429) 



reserved for future standardization 

3/9 3/9 

3/12 3/0 



reserved for private (experimental) use 

3/15 3/15 

Table 3: ANSI X3.64 mode-changing parameters used with the Select Mode and Reset 

jnode functions. ASCII characters 

are specified by column/row notation (see table 1). 


DeSmet 

C 

The fastest 
8088 C Compiler 
available 


FULL DEVELOPMENT PACKAGE 

■ C Compiler 

■ Assembler 

• Linker and Librarian 

• Full-Screen Editor 

• Newsletter for bugs/updates 

SYMBOLIC DEBUGGER 

• Monitor and change variables 
name using C expressions 

■ Multi-Screen support for debugging 
PC graphics and interactive systems 

• Optionally display C source during 
execution 

■ Breakpoint by Function and Line # 

COMPLETE IMPLEMENTATION 

• Both 1.0 and 2.0 DOS support 

■ Everything in K&R (incl. STDIO) 

■ Intel assembler mnemonics 

• Both 8087 and Software Floating Point 

OUTSTANDING PERFORMANCE 

Sieve Benchmark 


by 


COMPILE 


UNK 


RUN 

SIZE 


4 Sec. RAM - 
22 Sec FDISK 
6 Sec. RAM — 
34 Sec. FDISK 
12 Sec. 

8192 bytes 


DeSmet C 
Devetopment Package 


To Order Specify: 
Machine 


led on page 373 


OS □ MS-DOS □ CP/M-86 
Disk □ 8” □ 5’/. SS - □ 5'A DS 

C WARE 

CORPORATION 

P.O. BOX 710097 
San Jose, CA 95171-0097 
(408) 736-6905 

California residents add sales lax. Shipping: U.S. no 
charge Canada add $5. elsewhere add $15. Checks 
must be on a US Bank and in US Oollars 
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1 

t 

I 

I 

I 

I 

t 

1 

1 

I 

I 

I 

I 

1 

I 


—MODEMS— 

'Signalman MARK XII S249.95 
1200/300 Baud Auto Dial/Ans 
Hayes™ Compatible 

'VOSKMODEM 300 BaudJ59.95 
Limited Offer/FREE Source Memb. 

'The Computer Phone Book$9.95 

'The Complete Handbook of 
Personal Computer Comm. ST 2.95 

—COMPUTER— 

Sanyo MBC-550 $845 

Order: (800) 235-6646 OP 555 
Calif. (800) 235-6647 OP 555 

VISA/MC ACOM Electronics 
Add 3% Dept. 120 
Shipping 41 51 Middlefield Rd. 
Add 2% Palo Alto, CA 94303 


Circle 13 on inquiry card. 


COMPUTER SUPPLIES 



LABELS • CONTINUOUS FORMS 


PeachText 5000 reg 395- 235 00 

, x complete line of 

) EDUWARE SOFTWARE 

s plus other major brands 
=" , ‘Terms: Visa, M.C. or C.O.D. 

SL ‘Dealer Inquiries Invited 

Fmnmm COMPU-MEDIA 
SOFTWARE, INC. 
AUTHORIZED i59 Main St. S.I.N.Y. 10307 
distributor j CALL T0LL FREE 1-800-248-2418 
in N.Y. State 212-967-1700 


Circle 393 on inquiry card. 


VT102 



PCI 02™ SOFTWARE 
TURNS YOUR PC INTO A 
VT1 00/1 02/52 TERMINAL 

Requires: IBM type PC'. 64K. 1 drive. 25x80 display, 
async adpt. and IBM OOS or ONX. 

PRICED FROM $89. 

Optional: Local Printer 4 File Transfer 
Optional: 132-Column Support 
For more information call or write: 


g ms 


7525 MITCHELL ROAD. SUITE 101. MPLS MN 55344 
($12) 937-9194 


umn across from the left. The num- 
bers consist of the ASCII characters 
for one, seven, four, and five— all 
parameters in X3.64 are assumed to 
be in decimal radix. There are spaces 
shown here between the elements of 
the sequence for clarity, but no 
spaces should actually appear in a 
real command except where explicit- 
ly required. If no parameters are sup- 
plied, the command is executed with 
both parameters defaulting to 1, and 
the cursor goes to the home position. 

Flexibility and Expansion 

Functions similar to CUP exist to 
move the cursor to any position 
along a given line or down a column. 
Other functions can move the cursor 
relative to the position it has when 
the command is received. Editing 
functions include sequences to con- 
trol the insertion or deletion of in- 
dividual characters, strings of char- 
acters, or complete lines of text. More 
advanced functions allow the display 
screen to be divided into special- 
purpose fields that can be high- 
lighted, protected against change, or 
even rendered invisible. 

Other functions exist to specify 
operations that you'll hardly ever 
find in a video-display terminal. That 
should be no real surprise, because 
no one ever intended that all periph- 
eral devices should implement every 
part of the X3.64 standard. But the 
functions are there for use by flatbed 
plotters, typesetting equipment, and 
whatever else gets invented. 

The X3L2 committee left room for 
future expansion by reserving certain 
codes. Conscientious designers of ter- 
minals and software will take steps to 
ensure future compatibility: spelling 
out exactly which codes are used, 
avoiding the reserved codes, and not 
assigning nonstandard functions to 
control sequences used in the stan- 
dard. Avoiding conflict shouldn't be 
too hard: using only one intermediate 
character in control sequences, over 
1000 private function codes can be 
constructed. 

The development and increasing 
use of the X3.64 device-control stan- ■ 
dard promises to allow near-com- 
plete compatibility between different 
makes of video terminals. The con- 


trol sequences for all of the most 
common functions will be the same 
in any two video terminals that con- T< 
form to the standard, even if the two 
terminals were designed years and 
continents apart. A programmer;-, 
writing application software can use 
a set of ANSI X3.64 control se- • 
quences and remain confident that 
the software will work properly with 
any terminal that meets the stan- 
dard. And users will have greater 
range than ever before in choosing a 
video terminal that can work with 
their systems. ; 

There's not room here to cover all 
the details of all the functions in this ' 
article. To use the standard, you'll 
need a copy of the X3. 64-1979 docu- 
ment, which you can order from 
ANSI, 1430 Broadway, New York, 
NY 10018 for $17 plus $4 for postage. , 
Take time to study it; and use table 
2 in this article as a quick reference. ■ 
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